Update exploit-protection-reference.md

windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md

@@ -400,7 +400,7 @@ Additionally, by enabling EAF+, this mitigation adds the PAGE_GUARD protection t
 
 ### Description
 
-Address Space Layout Randomization (ASLR) mitigates the risk of an attacker using their knowledge of the memory layout of the system in order to execute code that is already present in process memory and already marked as executable. This can mitigate the risk of an attacker leveraging techniques such as return-to-libc attacks, where the adversary sets the context and then modifies the return address to execute existing code with context that suits the adversary's purpose.
+Address Space Layout Randomization (ASLR) mitigates the risk of an attacker using their knowledge of the memory layout of the system in order to execute code that is already present in process memory and already marked as executable. This can mitigate the risk of an attacker using techniques such as return-to-libc attacks, where the adversary sets the context and then modifies the return address to execute existing code with context that suits the adversary's purpose.
 
 Mandatory ASLR forces a rebase of all DLLs within the process. A developer can enable ASLR using the [/DYNAMICBASE](https://docs.microsoft.com/cpp/build/reference/dynamicbase-use-address-space-layout-randomization?view=vs-2019&preserve-view=true) linker option, and this mitigation has the same effect.
 
@@ -471,7 +471,7 @@ The size of the 32-bit address space places practical constraints on the entropy
 
 ### Compatibility considerations
 
-Most applications that are compatible with Mandatory ASLR (rebasing) will also be compatible with the additional entropy of Bottom-up ASLR. Some applications may have pointer-truncation issues if they are saving local pointers in 32-bit variables (expecting a base address below 4 GB), and thus will be incompatible with the high entropy option (which can be disabled).
+Most applications that are compatible with Mandatory ASLR (rebasing) are also compatible with the other entropy of Bottom-up ASLR. Some applications may have pointer-truncation issues if they are saving local pointers in 32-bit variables (expecting a base address below 4 GB), and thus will be incompatible with the high entropy option (which can be disabled).
 
 ### Configuration options
 
@@ -594,7 +594,7 @@ This mitigation is incompatible with the Arbitrary Code Guard mitigation.
 
 ### Description
 
-Validate exception chains (SEHOP) is a mitigation against the *Structured Exception Handler (SEH) overwrite* exploitation technique. [Structured exception handling](https://docs.microsoft.com/windows/win32/debug/structured-exception-handling) is the process by which an application can ask to handle a particular exception. Exception handlers are chained together, so that if one exception handler chooses not to handle a particular exception, it can be passed on to the next exception handler in the chain until one decides to handle it. Because the list of handler is dynamic, it is stored on the stack. An attacker can leverage a stack overflow vulnerability to then overwrite the exception handler with a pointer to the code of the attacker's choice.
+Validate exception chains (SEHOP) is a mitigation against the *Structured Exception Handler (SEH) overwrite* exploitation technique. [Structured exception handling](https://docs.microsoft.com/windows/win32/debug/structured-exception-handling) is the process by which an application can ask to handle a particular exception. Exception handlers are chained together, so that if one exception handler chooses not to handle a particular exception, it can be passed on to the next exception handler in the chain until one decides to handle it. Because the list of handler is dynamic, it is stored on the stack. An attacker can use a stack overflow vulnerability to then overwrite the exception handler with a pointer to the code of the attacker's choice.
 
 This mitigation relies on the design of SEH, where each SEH entry contains both a pointer to the exception handler, as well as a pointer to the next handler in the exception chain. This mitigation is called by the exception dispatcher, which validates the SEH chain when an exception is invoked. It verifies that:
 
@@ -619,7 +619,7 @@ Compatibility issues with SEHOP are relatively rare. It's uncommon for an applic
 
 ### Description
 
-*Validate handle usage* is a mitigation that helps protect against an attacker leveraging an existing handle to access a protected object. A [handle](https://docs.microsoft.com/windows/win32/sysinfo/handles-and-objects) is a reference to a protected object. If application code is referencing an invalid handle, that could indicate that an adversary is attempting to use a handle it has previously recorded (but which application reference counting wouldn't be aware of). If the application attempts to use an invalid object, instead of simply returning null, the application will raise an exception (STATUS_INVALID_HANDLE).
+*Validate handle usage* is a mitigation that helps protect against an attacker using an existing handle to access a protected object. A [handle](https://docs.microsoft.com/windows/win32/sysinfo/handles-and-objects) is a reference to a protected object. If application code is referencing an invalid handle, that could indicate that an adversary is attempting to use a handle it has previously recorded (but which application reference counting wouldn't be aware of). If the application attempts to use an invalid object, instead of simply returning null, the application will raise an exception (STATUS_INVALID_HANDLE).
 
 This mitigation is automatically applied to Windows Store applications.
 
@@ -639,7 +639,7 @@ Applications that were not accurately tracking handle references, and which were
 The *validate heap integrity* mitigation increases the protection level of heap mitigations in Windows, by causing the application to terminate if a heap corruption is detected. The mitigations include:
 
 - Preventing a HEAP handle from being freed
-- Performing additional validation on extended block headers for heap allocations
+- Performing another validation on extended block headers for heap allocations
 - Verifying that heap allocations are not already flagged as in-use
 - Adding guard pages to large allocations, heap segments, and subsegments above a minimum size
 
@@ -672,7 +672,7 @@ Compatibility issues are uncommon. Applications that depend on replacing Windows
 
 The *validate stack integrity (StackPivot)* mitigation helps protect against the Stack Pivot attack, a ROP attack where an attacker creates a fake stack in heap memory, and then tricks the application into returning into the fake stack that controls the flow of execution.
 
-This mitigation intercepts a number of Windows APIs, and inspects the value of the stack pointer. If the address of the stack pointer does not fall between the bottom and the top of the stack, then an event is recorded and, if not in audit mode, the process will be terminated.
+This mitigation intercepts many Windows APIs, and inspects the value of the stack pointer. If the address of the stack pointer does not fall between the bottom and the top of the stack, then an event is recorded and, if not in audit mode, the process will be terminated.
 
 The APIs intercepted by this mitigation are:
 
@@ -713,7 +713,7 @@ The APIs intercepted by this mitigation are:
 
 ### Compatibility considerations
 
-Applications that are leveraging fake stacks will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications.
+Applications that are using fake stacks will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications.
 Applications that perform API interception, particularly security software, can cause compatibility problems with this mitigation.
 
 This mitigation is incompatible with the Arbitrary Code Guard mitigation.