mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 11:53:37 +00:00
Update exploit-protection-reference.md
This commit is contained in:
@ -11,7 +11,7 @@ ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
author: denisebmsft
|
||||
ms.author: deniseb
|
||||
ms.date: 07/20/2020
|
||||
ms.date: 01/06/2021
|
||||
ms.reviewer: cjacks
|
||||
manager: dansimp
|
||||
ms.custom: asr
|
||||
@ -223,7 +223,7 @@ Block low integrity images will prevent the application from loading files that
|
||||
|
||||
### Description
|
||||
|
||||
Block remote images will prevent the application from loading files that are hosted on a remote device, such as a UNC share. This helps protect against loading binaries into memory that are on an external device controlled by the attacker.
|
||||
Blocking remote images helps to prevent the application from loading files that are hosted on a remote device, such as a UNC share. Blocking remote images helps protect against loading binaries into memory that are on an external device controlled by the attacker.
|
||||
|
||||
This mitigation will block image loads if the image is determined to be on a remote device. It is implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a remote file, it will trigger a STATUS_ACCESS_DENIED error.
|
||||
|
||||
@ -257,7 +257,7 @@ The most common use of fonts outside of the system fonts directory is with [web
|
||||
|
||||
### Description
|
||||
|
||||
Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. This includes [WHQL](https://docs.microsoft.com/windows-hardware/drivers/install/whql-release-signature) (Windows Hardware Quality Labs) signatures, which will allow WHQL-approved drivers to run within the process.
|
||||
Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. Code integrity guard includes [WHQL](https://docs.microsoft.com/windows-hardware/drivers/install/whql-release-signature) (Windows Hardware Quality Labs) signatures, which will allow WHQL-approved drivers to run within the process.
|
||||
|
||||
This mitigation is implemented within the memory manager, which blocks the binary from being mapped into memory. If you attempt to load a binary that is not signed by Microsoft, the memory manger will return the error STATUS_INVALID_IMAGE_HASH. By blocking at the memory manager level, this prevents both binaries loaded by the process and binaries injected into the process.
|
||||
|
||||
@ -275,9 +275,9 @@ This mitigation specifically blocks any binary that is not signed by Microsoft.
|
||||
|
||||
### Description
|
||||
|
||||
Control flow guard (CFG) mitigates the risk of attackers leveraging memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker may user a buffer overflow vulnerability to overwrite memory containing a function pointer, and replace that function pointer with a pointer to executable code of their choice (which may also have been injected into the program).
|
||||
Control flow guard (CFG) mitigates the risk of attackers using memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker may user a buffer overflow vulnerability to overwrite memory containing a function pointer, and replace that function pointer with a pointer to executable code of their choice (which may also have been injected into the program).
|
||||
|
||||
This mitigation is provided by injecting an additional check at compile time. Before each indirect function call, additional instructions are added which verify that the target is a valid call target before it is called. If the target is not a valid call target, then the application is terminated. As such, only applications that are compiled with CFG support can benefit from this mitigation.
|
||||
This mitigation is provided by injecting another check at compile time. Before each indirect function call, another instructions are added which verify that the target is a valid call target before it is called. If the target is not a valid call target, then the application is terminated. As such, only applications that are compiled with CFG support can benefit from this mitigation.
|
||||
|
||||
The check for a valid target is provided by the Windows kernel. When executable files are loaded, the metadata for indirect call targets is extracted at load time and marked as valid call targets. Additionally, when memory is allocated and marked as executable (such as for generated code), these memory locations are also marked as valid call targets, to support mechanisms such as JIT compilation.
|
||||
|
||||
@ -296,7 +296,7 @@ Since applications must be compiled to support CFG, they implicitly declare thei
|
||||
|
||||
### Description
|
||||
|
||||
Data execution prevention (DEP) prevents memory that was not explicitly allocated as executable from being executed. This helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code.
|
||||
Data execution prevention (DEP) prevents memory that was not explicitly allocated as executable from being executed. DEP helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code.
|
||||
|
||||
If you attempt to set the instruction pointer to a memory address not marked as executable, the processor will throw an exception (general-protection violation), causing the application to crash.
|
||||
|
||||
@ -304,7 +304,7 @@ If you attempt to set the instruction pointer to a memory address not marked as
|
||||
|
||||
All x64, ARM, and ARM-64 executables have DEP enabled by default, and it cannot be disabled. Since an application will have never been executed without DEP, compatibility is assumed.
|
||||
|
||||
All x86 (32-bit) binaries will have DEP enabled by default, but it can be disabled per process. Some old legacy applications, typically applications developed prior to Windows XP SP2, may not be compatible with DEP. These are typically applications that dynamically generate code (for example, JIT compiling) or link to older libraries (such as older versions of ATL) which dynamically generate code.
|
||||
All x86 (32-bit) binaries have DEP enabled by default, but DEP can be disabled per process. Some old legacy applications, typically applications developed prior to Windows XP SP2, might not be compatible with DEP. Such applications typically generate code dynamically (for example, JIT compiling) or link to older libraries (such as older versions of ATL) which dynamically generate code.
|
||||
|
||||
### Configuration options
|
||||
|
||||
|
Reference in New Issue
Block a user