Referencia de protección contra vulnerabilidades

Se aplica a: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Protección contra vulnerabilidades de seguridad proporciona protecciones avanzadas para las aplicaciones que los administradores empresariales y los profesionales de TI pueden aplicar después de que un desarrollador compile y distribuya software.

Este artículo le ayuda a comprender cómo funciona la protección contra vulnerabilidades de seguridad, tanto en el nivel de directiva como en el nivel de mitigación individual, para ayudarle a crear y aplicar correctamente directivas de protección contra vulnerabilidades de seguridad.

Cómo se aplican las mitigaciones

Las mitigaciones de protección contra vulnerabilidades se aplican para cada aplicación.

Cada programa tiene su propia entrada del Registro que controla qué mitigaciones se aplican. Esta configuración se almacena en la entrada del Registro MitigationOptions (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Esta configuración de mitigación surte efecto al reiniciar el programa. Permanecen activos hasta que los cambie y reinicie el programa.

Importante

Las opciones de ejecución de archivos de imagen solo permiten especificar un nombre de archivo o una ruta de acceso. No se puede especificar un número de versión, una arquitectura ni ningún otro diferenciador. Aplica las mitigaciones a las aplicaciones con nombres o rutas únicos. Aplíquelos solo en dispositivos en los que haya probado esa versión y arquitectura de la aplicación.

Puede configurar mitigaciones a través de un archivo XML mediante PowerShell, directiva de grupo o MDM. Cuando se usa un archivo XML, el sistema establece las entradas del Registro automáticamente.

Restablecer la protección contra exploits

Importante

Cuando la directiva de grupo o la directiva MDM que implementa el archivo XML ya no se aplican, la configuración implementada por este archivo de configuración XML no se quitará automáticamente.

Para quitar la configuración de protección contra vulnerabilidades de seguridad, exporte la configuración XML desde un dispositivo Windows 10 o Windows 11 limpio e implemente este nuevo archivo XML. Como alternativa, Microsoft proporciona un archivo XML como parte de las líneas base de Seguridad de Windows para restablecer la configuración de protección contra vulnerabilidades de seguridad.

Para restablecer la configuración de protección contra vulnerabilidades mediante PowerShell, ejecute el siguiente comando para aplicar la directiva de restablecimiento del archivo XML y restaurar la configuración de mitigación a sus valores predeterminados:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

El siguiente archivo XML es el EP-reset.xml incluido con las Líneas base de seguridad de Windows. Este archivo define invalidaciones de mitigación por aplicación que restablecen la configuración de protección contra vulnerabilidades a sus valores predeterminados para aplicaciones comunes, como Microsoft Office, exploradores web y reproductores multimedia:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
  <AppConfig Executable="ONEDRIVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR OverrideRelocateImages="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
  </AppConfig>
  <AppConfig Executable="firefox.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
  </AppConfig>
  <AppConfig Executable="fltldr.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="GROOVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="Acrobat.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="AcroRd32.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="chrome.exe">
    <DEP OverrideDEP="false" />
  </AppConfig>
  <AppConfig Executable="EXCEL.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="iexplore.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="INFOPATH.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="java.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaw.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaws.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="LYNC.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSACCESS.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSPUB.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OIS.EXE">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OUTLOOK.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="plugin-container.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="POWERPNT.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="PPTVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VISIO.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VPREVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="WINWORD.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wmplayer.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wordpad.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
</MitigationPolicy>

Referencia de mitigación

Las siguientes mitigaciones de protección contra vulnerabilidades incluyen una descripción, consideraciones de compatibilidad y opciones de configuración.

Protección de código arbitrario

En las secciones siguientes se describe cómo funciona la protección de código arbitraria, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

La protección de código arbitraria ayuda a protegerse contra un atacante malintencionado que cargue el código de su elección en la memoria a través de una vulnerabilidad de seguridad de la memoria y sea capaz de ejecutar ese código.

Protección de código arbitraria protege a una aplicación de la ejecución de código generado dinámicamente (código que no se carga, por ejemplo, desde el propio archivo exe o un archivo DLL). La protección de código arbitraria funciona evitando que la memoria se marque como ejecutable. Cuando una aplicación intenta asignar memoria, comprobamos las marcas de protección. (La memoria se puede asignar con marcas de protección de lectura, escritura y/o ejecución). Si la asignación intenta incluir la marca de protección de ejecución, se produce un error en la asignación de memoria y devuelve un código de error (STATUS_DYNAMIC_CODE_BLOCKED). Del mismo modo, si una aplicación intenta cambiar las marcas de protección de la memoria que ya se ha asignado e incluye la marca de protección de ejecución, el cambio de permisos produce un error y devuelve un código de error (STATUS_DYNAMIC_CODE_BLOCKED).

Al impedir que se establezca el indicador de ejecución, la función de Prevención de ejecución de datos de Windows 10 y Windows 11 puede proteger contra que el puntero de instrucción apunte a esa memoria y ejecute ese código.

Consideraciones de compatibilidad

La protección de código arbitraria impide asignar memoria como ejecutable, lo que presenta un problema de compatibilidad con enfoques como los compiladores Just-In-Time (JIT). La mayoría de los exploradores modernos, por ejemplo, compilan JavaScript en código nativo para optimizar el rendimiento. Para admitir esta mitigación, deben rediseñarse para mover la compilación JIT fuera del proceso protegido. Otras aplicaciones cuyo diseño genera código dinámicamente a partir de scripts u otros lenguajes intermedios son igualmente incompatibles con esta mitigación.

Opciones de configuración

Permitir la exclusión de subprocesos: puede configurar la mitigación para permitir que un subproceso individual se excluya en esta protección. El desarrollador debe escribir la aplicación con conocimiento de esta mitigación y llamar a la API SetThreadInformation con el parámetro ThreadInformation establecido en ThreadDynamicCodePolicy para poder ejecutar código dinámico en este subproceso.

Solo auditoría : puede habilitar esta mitigación en modo de auditoría para medir el posible efecto de compatibilidad en una aplicación. Los eventos de auditoría se pueden ver después ya sea en el Visor de eventos o mediante Búsqueda avanzada en Microsoft Defender for Endpoint.

Bloquear imágenes de integridad baja

En las secciones siguientes se describe cómo funcionan las imágenes de baja integridad en bloques, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Bloquear imágenes de baja integridad impide que la aplicación cargue archivos que no son de confianza, normalmente porque se han descargado de Internet desde un explorador de espacio aislado.

Esta mitigación bloquea la carga de imágenes si la imagen tiene una entrada de control de acceso (ACE) que concede acceso a procesos con IL bajo y no tiene una ACE de etiqueta de confianza. Lo implementa el administrador de memoria, lo que impide que el archivo se asigne a la memoria. Si una aplicación intenta cargar una imagen de baja integridad, se produce el error STATUS_ACCESS_DENIED. Para obtener más detalles sobre cómo funcionan los niveles de integridad, consulte Control de integridad obligatorio.

Consideraciones de compatibilidad

Bloquear imágenes de baja integridad impide que la aplicación cargue archivos que se descargaron de Internet. Si el flujo de trabajo de su aplicación requiere cargar imágenes descargadas, debe asegurarse de que se descarguen desde un proceso de mayor confianza o de que se reetiqueten explícitamente para aplicar esta mitigación.

Opciones de configuración

Solo auditoría : puede habilitar esta mitigación en modo de auditoría para medir el posible efecto de compatibilidad en una aplicación. Los eventos de auditoría pueden verse entonces ya sea en el visor de eventos o con Búsqueda avanzada en Microsoft Defender para punto de conexión.

Bloquear imágenes remotas

Las siguientes secciones describen cómo funciona el bloqueo de imágenes remotas, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Bloquear imágenes remotas ayuda a evitar que la aplicación cargue archivos hospedados en un dispositivo remoto, como un recurso compartido UNC. El bloqueo de imágenes remotas ayuda a proteger contra la carga de archivos binarios en la memoria que se encuentran en un dispositivo externo controlado por el atacante.

Esta mitigación bloquea las cargas de imágenes si se determina que la imagen está en un dispositivo remoto. Lo implementa el administrador de memoria, lo que impide que el archivo se asigne a la memoria. Si una aplicación intenta asociar un archivo remoto, se desencadena el error STATUS_ACCESS_DENIED.

Consideraciones de compatibilidad

Bloquear imágenes remotas impide que la aplicación cargue imágenes desde dispositivos remotos. Si la aplicación carga archivos o complementos desde dispositivos remotos, no será compatible con esta mitigación.

Opciones de configuración

Bloquear fuentes que no son de confianza

En las secciones siguientes se describe cómo funcionan las fuentes que no son de confianza en bloque, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Bloquear fuentes que no son de confianza mitiga el riesgo de un error en el análisis de fuentes, lo que hace que el atacante pueda ejecutar código en el dispositivo. GDI solo cargará las fuentes instaladas en el directorio windows\fonts para su procesamiento.

Esta mitigación se implementa en GDI, que valida la ubicación del archivo. Si el archivo no está en el directorio de fuentes del sistema, la fuente no se cargará para el análisis y se producirá un error en la llamada.

Esta mitigación se suma a la mitigación integrada proporcionada en Windows 10 1607 y versiones posteriores, y Windows 11, que mueve el análisis de fuentes fuera del kernel y a un contenedor de aplicaciones en modo de usuario. Cualquier vulnerabilidad de seguridad basada en el análisis de fuentes, como resultado, se produce en un contexto aislado y en una área restringida, lo que reduce significativamente el riesgo.

Consideraciones de compatibilidad

El uso más común de fuentes fuera del directorio de fuentes del sistema es con fuentes web. Los exploradores modernos, como Microsoft Edge, usan DirectWrite en lugar de GDI y no se ven afectados. Sin embargo, los exploradores heredados, como Internet Explorer 11 (y el modo IE en el nuevo Microsoft Edge) pueden verse afectados, especialmente con aplicaciones como Office 365, que usan glifos de fuente para mostrar la interfaz de usuario.

Opciones de configuración

Protección de integridad de código

En las secciones siguientes se describe cómo funciona la protección de integridad de código, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Protección de integridad de código garantiza que Microsoft firme digitalmente todos los archivos binarios cargados en un proceso. La protección de integridad de código incluye firmas WHQL (Windows Hardware Quality Labs), lo que permite que los controladores aprobados por WHQL se ejecuten dentro del proceso.

Esta mitigación se implementa en el administrador de memoria, que impide que el binario se asigne a la memoria. Si intenta cargar un archivo binario que no está firmado por Microsoft, el administrador de memoria devuelve el error STATUS_INVALID_IMAGE_HASH. Al bloquear en el nivel de administrador de memoria, impide que los binarios sean cargados por el proceso y los binarios sean insertados en el proceso.

Consideraciones de compatibilidad

Esta mitigación bloquea específicamente cualquier archivo binario que no esté firmado por Microsoft. Por lo tanto, es incompatible con la mayoría del software que no es de Microsoft, a menos que el software esté distribuido (y firmado digitalmente por) microsoft Store y se seleccione la opción para permitir la carga de imágenes firmadas por Microsoft Store.

Opciones de configuración

También permite la carga de imágenes firmadas por Microsoft Store : las aplicaciones distribuidas por Microsoft Store están firmadas digitalmente por Microsoft Store y agregar esta configuración permite que la aplicación cargue los archivos binarios que pasan por el proceso de certificación de la tienda.

Protección del flujo de control (CFG)

En las secciones siguientes se describe cómo funciona la protección de flujo de control, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Control Flow Guard (CFG) mitiga el riesgo de que los atacantes aprovechen vulnerabilidades de corrupción de memoria al proteger las llamadas indirectas a funciones. Por ejemplo, un atacante podría usar una vulnerabilidad de desbordamiento de búfer para sobrescribir la memoria que contiene un puntero de función y reemplazar ese puntero de función por un puntero al código ejecutable de su elección (que también se podría insertar en el programa).

Esta mitigación se proporciona mediante la inserción de otra comprobación en tiempo de compilación. Antes de cada llamada de función indirecta, se agregan otras instrucciones que comprueban que el destino es un destino de llamada válido antes de llamarlo. Si el destino no es un destino de llamada válido, la aplicación finaliza. Por lo tanto, solo las aplicaciones compiladas con compatibilidad con CFG pueden beneficiarse de esta mitigación.

El kernel de Windows proporciona la comprobación de un destino válido. Cuando se cargan archivos ejecutables, los metadatos de los destinos de llamada indirectos se extraen en tiempo de carga y se marcan como destinos de llamada válidos. Además, cuando se asigna memoria y se marca como ejecutable (por ejemplo, para el código generado), estas ubicaciones de memoria también se marcan como destinos de llamada válidos, para admitir mecanismos como la compilación JIT.

Consideraciones de compatibilidad

Dado que las aplicaciones deben compilarse para admitir CFG, declaran implícitamente su compatibilidad con él. Por lo tanto, la mayoría de las aplicaciones deben funcionar con esta mitigación habilitada. Dado que estas comprobaciones se compilan en el binario, la configuración que puede aplicar es simplemente deshabilitar las comprobaciones dentro del kernel de Windows. En otras palabras, la mitigación está activada de forma predeterminada, pero puede configurar el kernel de Windows para que siempre devuelva "sí" si más adelante determina que hay un problema de compatibilidad que el desarrollador de la aplicación no detectó en sus pruebas, lo que debería ser poco frecuente.

Opciones de configuración

Usar CFG en modo estricto - En modo estricto, todos los binarios cargados en el proceso deben haberse compilado para Control Flow Guard o no tener código ejecutable, como las DLL de recursos, para poder cargarse.

Nota:

Control flow guard no tiene modo de auditoría. Los archivos binarios se compilan con esta mitigación habilitada.

Prevención de ejecución de datos (DEP)

En las secciones siguientes se describe cómo funciona la prevención de ejecución de datos, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

La prevención de ejecución de datos (DEP) impide que se ejecute la memoria que no se asignó explícitamente como ejecutable. La DEP ayuda a protegerse contra un atacante que inserta código malintencionado en el proceso, como a través de un desbordamiento del búfer, y luego ejecuta ese código.

Si intenta establecer el puntero de instrucción en una dirección de memoria no marcada como ejecutable, el procesador produce una excepción (infracción de protección general), lo que provoca que la aplicación se bloquee.

Consideraciones de compatibilidad

Todos los archivos ejecutables x64, ARM y Arm64 tienen DEP habilitado de forma predeterminada y no se puede deshabilitar. Dado que una aplicación no se ejecuta sin DEP, se asume la compatibilidad.

Todos los archivos binarios x86 (32 bits) tienen la DEP habilitada de forma predeterminada, pero la DEP se puede deshabilitar por proceso. Es posible que algunas aplicaciones heredadas antiguas, normalmente aplicaciones desarrolladas antes de Windows XP SP2, no sean compatibles con DEP. Estas aplicaciones suelen generar código dinámicamente (por ejemplo, compilación JIT) o vincular a bibliotecas anteriores (como versiones anteriores de ATL) que generan código dinámicamente.

Opciones de configuración

Habilitar emulación ATL Thunk : esta opción controla la emulación ATL Thunk. ATL, la biblioteca de plantillas ActiveX, está diseñada para ser lo más pequeña y rápida posible. Para reducir el tamaño binario, usa una técnica denominada thunking. El thunking suele estar vinculado a la interacción de 32 y 16 bits, pero ATL no tiene partes de 16 bits. En su lugar, para ahorrar espacio, ATL almacena código de máquina en memoria que no está alineado con palabras. Esto crea un binario más pequeño. A continuación, ATL ejecuta ese código directamente. Las versiones ATL compiladas con Visual Studio 7.1 o versiones anteriores (Visual Studio 2003) no marcan esta memoria como ejecutable. La emulación de Thunk corrige ese problema. Las aplicaciones con un modelo de extensión binaria (como Internet Explorer 11) necesitan la emulación ATL Thunk habilitada.

Deshabilitar los puntos de extensión

En las secciones siguientes se describe cómo funciona la mitigación de deshabilitar los puntos de extensión, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

La mitigación de deshabilitar puntos de extensión deshabilita varios puntos de extensión de una aplicación, que podrían usarse para mantener la persistencia o elevar los privilegios de contenido malintencionado.

Esto incluye lo siguiente:

Archivos DLL de AppInit : cada vez que se inicia un proceso, el sistema carga el archivo DLL especificado en el contexto del proceso recién iniciado antes de llamar a su función de punto de entrada. Más información sobre los archivos DLL de AppInit aquí. Con esta mitigación aplicada, no se cargan los archivos DLL de AppInit. A partir de Windows 7, los archivos DLL de AppInit deben estar firmados digitalmente, como se describe aquí. Además, a partir de Windows 8, los archivos DLL de AppInit no se cargarán si SecureBoot está habilitado, como se describe aquí.
IME heredados - Un IME (editor de método de entrada) permite al usuario escribir texto en un idioma que tiene más caracteres de los que puede representar un teclado. Los terceros pueden crear IME. Un IME malintencionado podría obtener credenciales u otra información confidencial de esta captura de entrada. Algunos IME, denominados MIE heredados, solo funcionan en aplicaciones de escritorio de Windows y no en aplicaciones para UWP. Esta mitigación también impide que este IME heredado se cargue en la aplicación de escritorio de Windows especificada.
Windows Event Hooks: una aplicación puede llamar a la API SetWinEventHook para registrar su interés en un evento que se está desarrollando. Se especifica un archivo DLL y se puede insertar en el proceso. Esta mitigación obliga a que el enlace se publique en el proceso de registro en lugar de ejecutarse en proceso a través de un archivo DLL insertado.

Consideraciones de compatibilidad

La mayoría de estos puntos de extensión se utilizan relativamente poco, por lo que el impacto en la compatibilidad suele ser pequeño, especialmente a nivel de cada aplicación. La única consideración es si los usuarios usan MIE heredadas que no son de Microsoft que no funcionarán con la aplicación protegida.

Opciones de configuración

No hay opciones de configuración para esta mitigación.

Nota:

Deshabilitar puntos de extensión no tiene modo de auditoría.

Deshabilitar llamadas del sistema de Win32k

En las secciones siguientes se describe cómo funciona la deshabilitación de las llamadas al sistema Win32k, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

Win32k.sys proporciona una amplia superficie de ataque para un atacante. Como componente en modo núcleo, suele ser objeto de ataques como vector de escape para aplicaciones en entorno aislado. Esta mitigación impide que las llamadas a win32k.sys bloqueen un subproceso para que no se convierta a sí mismo en un subproceso de GUI, al que se concede acceso para invocar funciones Win32k. Un hilo no es de GUI cuando se crea, pero se convierte en uno de GUI con la primera llamada a win32k.sys o mediante una llamada a la API IsGuiThread.

Consideraciones de compatibilidad

Esta mitigación está diseñada para procesos dedicados que no son de interfaz de usuario. Por ejemplo, muchos exploradores modernos usan el aislamiento de procesos e incorporan procesos que no son de interfaz de usuario. Cualquier aplicación que muestre una GUI mediante un único proceso se verá afectada por esta mitigación.

Opciones de configuración

No permitir procesos secundarios

En las secciones siguientes se describe cómo funciona la mitigación «No permitir procesos secundarios», su impacto en la compatibilidad y sus opciones de configuración.

Descripción

La mitigación «No permitir procesos secundarios» impide que una aplicación cree nuevos procesos secundarios. Una técnica común utilizada por los atacantes consiste en iniciar un proceso confiable en el dispositivo con una entrada maliciosa (un ataque que aprovecha herramientas legítimas del sistema), lo que a menudo requiere ejecutar otra aplicación en el dispositivo. Si no hay razones legítimas para que una aplicación inicie un proceso secundario, esta mitigación mitiga ese potencial vector de ataque. La mitigación se aplica estableciendo una propiedad en el token de proceso, que bloquea la creación de un token para el proceso secundario con el mensaje de error STATUS_CHILD_PROCESS_BLOCKED.

Consideraciones de compatibilidad

Si la aplicación inicia aplicaciones secundarias por cualquier motivo, como admitir hipervínculos que inician un explorador o un explorador externo, o que inician otras utilidades en el equipo, esta funcionalidad se interrumpe con esta mitigación aplicada.

Opciones de configuración

Exportar filtrado de direcciones

En las secciones siguientes se describe cómo funciona el filtrado de direcciones de exportación, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

El filtrado de direcciones de exportación (EAF) mitiga el riesgo de que el código malintencionado examine la tabla de direcciones de exportación de todos los módulos cargados para buscar módulos que contengan API útiles para su ataque. Se trata de una táctica común usada por shellcode. Para mitigar el riesgo de un ataque de este tipo, esta mitigación protege tres módulos que suelen atacarse:

ntdll.dll
kernelbase.dll
kernel32.dll

La mitigación protege la página de memoria en el [directorio de exportación que apunta a exportar tabla de direcciones. Esta página de memoria tiene aplicada la protección PAGE_GUARD . Cuando alguien intenta acceder a esta memoria, genera un STATUS_GUARD_PAGE_VIOLATION. La mitigación controla esta excepción y, si la instrucción de acceso no pasa la validación, el proceso finaliza.

Consideraciones de compatibilidad

Esta mitigación es principalmente un problema para aplicaciones como depuradores, aplicaciones de espacio aislado, aplicaciones que usan DRM o aplicaciones que implementan tecnología antidepuración.

Opciones de configuración

Valide el acceso para los módulos que suelen ser objeto de abuso por vulnerabilidades: esta opción, también conocida como EAF+, agrega protecciones para otros módulos que suelen atacarse:

mshtml.dll
flash*.ocx
jscript*.ocx
vbscript.dll
vgx.dll
mozjs.dll
xul.dll
acrord32.dll
acrofx32.dll
acroform.api

Además, al habilitar EAF+, esta mitigación agrega la protección PAGE_GUARD a la página que contiene el encabezado "MZ", los primeros 2 bytes del encabezado DOS en un archivo PE, este es un aspecto del contenido de memoria conocido que shellcode puede buscar para identificar módulos potencialmente interesantes en la memoria.

Forzar la selección aleatoria de imágenes (ASLR es obligatorio)

En las secciones siguientes se describe cómo funciona AsLR obligatorio, su impacto en la compatibilidad y sus opciones de configuración.

Descripción

La aleatorización de diseño de espacio de direcciones (ASLR) mitiga el riesgo de que un atacante use su conocimiento del diseño de memoria del sistema para ejecutar código que ya está presente en la memoria de proceso y que ya está marcado como ejecutable. Esto puede mitigar el riesgo de que un atacante use técnicas como ataques de retorno a libc, donde el adversario establece el contexto y, a continuación, modifica la dirección de retorno para ejecutar el código existente con el contexto que se adapte al propósito del adversario.

El ASLR obligatorio obliga a reasignar la dirección base de todas las DLL en el proceso. Un desarrollador puede habilitar el ASLR mediante la opción del enlazador /DYNAMICBASE y esta mitigación tiene el mismo efecto.

Cuando el administrador de memoria asigna la imagen en el proceso, ASLR obligatorio forzará la reubicación de los archivos DLL y EXE que no se hayan acogido a ASLR. Sin embargo, tenga en cuenta que esta reasignación de base no tiene entropía y, por lo tanto, puede ubicarse en una posición predecible de la memoria. Para la reubicación aleatoria de los binarios, esta mitigación debe combinarse con Aleatorizar las asignaciones de memoria (ASLR de abajo arriba).

Consideraciones de compatibilidad

Este efecto de compatibilidad de ASLR suele restringirse a aplicaciones anteriores que se crearon mediante compiladores que realizaron suposiciones sobre la dirección base de un archivo binario o que han eliminado la información de reubicación base. Esto puede provocar errores imprevisibles a medida que el flujo de ejecución intenta saltar a la ubicación esperada, en lugar de a la real, en la memoria.

Opciones de configuración

No permitir imágenes eliminadas : esta opción bloquea la carga de imágenes que tienen información de reubicación eliminada. El formato de archivo de Windows PE contiene direcciones absolutas y el compilador también genera una [tabla de reubicación base que el cargador puede usar para buscar todas las referencias de memoria relativas y su desplazamiento, de modo que se puedan actualizar si el binario no se carga en su dirección base preferida. Algunas aplicaciones anteriores quitan esta información en las compilaciones de producción y, por tanto, estos archivos binarios no se pueden volver a basar. Esta mitigación impide que se carguen estos binarios (en lugar de permitirles que los carguen en su dirección base preferida).

Nota:

Forzar aleatorización para imágenes (ASLR obligatorio) no tiene modo de auditoría.

Protección de pila aplicada por hardware

Descripción

La protección de pila impuesta por hardware ofrece una sólida protección contra ataques ROP. Funciona manteniendo un registro del flujo de ejecución previsto de un programa. Para facilitar una adopción fluida y la compatibilidad con las aplicaciones, Windows ofrece esta protección como un modelo de adhesión voluntaria. Los desarrolladores pueden habilitarlo a su propio ritmo.

Consideraciones de compatibilidad

La protección de pila impuesta por hardware solo funciona en chipsets compatibles con pilas sombra de hardware, la Tecnología de aplicación del flujo de control (CET) de Intel o las pilas sombra de AMD.

Si ejecuta aplicaciones basadas en .NET Framework, la protección de pila impuesta por hardware funciona con .NET Framework 7 (opcional) o versiones posteriores. Si usa una versión anterior, podría experimentar bloqueos o un uso elevado de CPU. Estos problemas también pueden producirse en el modo de auditoría o cuando se seleccionan únicamente módulos compatibles.

Opciones de configuración

Aplicar para todos los módulos en lugar de módulos compatibles : puede habilitar esta mitigación para aplicar para todos los módulos en lugar de módulos compatibles.

Filtrado de direcciones de importación (IAF)

Descripción

La mitigación del filtrado de direcciones de importación (IAF) ayuda a mitigar el riesgo de que un adversario cambie el flujo de control de una aplicación modificando la tabla de direcciones de importación (IAT) para redirigir a un código arbitrario de la elección del atacante cuando se llama a esa función. Un atacante podría usar este enfoque para secuestrar el control o interceptar, inspeccionar y bloquear potencialmente las llamadas a API confidenciales.

Las páginas de memoria de todas las API protegidas tienen aplicada la protección PAGE_GUARD . Cuando alguien intenta acceder a esta memoria, genera un STATUS_GUARD_PAGE_VIOLATION. La mitigación controla esta excepción y, si la instrucción de acceso no pasa la validación, el proceso finaliza.

Esta mitigación protege las siguientes API de Windows:

GetProcAddress
GetProcAddressForCaller
LoadLibraryA
LoadLibraryExA
LoadLibraryW
LoadLibraryExW
LdrGetProcedureAddress
LdrGetProcedureAddressEx
LdrGetProcedureAddressForCaller
LdrLoadDll
VirtualProtect
VirtualProtectEx
VirtualAlloc
VirtualAllocEx
NtAllocateVirtualMemory
NtProtectVirtualMemory
CreateProcessA
CreateProcessW
WinExec
CreateProcessAsUserA
CreateProcessAsUserW
GetModuleHandleA
GetModuleHandleW
RtlDecodePointer
DecodePointer

Consideraciones de compatibilidad

Esta mitigación puede detectar aplicaciones legítimas que realizan la interceptación de API y provocar que algunas aplicaciones se bloqueen. Algunos ejemplos son el software de seguridad y las capas de compatibilidad de aplicaciones.

Opciones de configuración

Aleatorizar las asignaciones de memoria (ASLR de abajo a arriba)

Descripción

La aleatorización de asignaciones de memoria (ASLR de abajo a arriba) agrega entropía a las reubicaciones, por lo que su ubicación es aleatoria y, por tanto, menos predecible. Esta mitigación requiere ASLR obligatorio para surtir efecto.

El tamaño del espacio de direcciones de 32 bits impone restricciones prácticas en la entropía que se puede agregar y, por lo tanto, las aplicaciones de 64 bits dificultan que un atacante adivine una ubicación en la memoria.

Consideraciones de compatibilidad

La mayoría de las aplicaciones que funcionan con ASLR obligatorio (rebasing) también funcionan con ASLR de abajo arriba. Es posible que algunas aplicaciones tengan problemas de truncamiento de puntero si guardan punteros locales en variables de 32 bits. Estas aplicaciones esperan una dirección base por debajo de 4 GB, por lo que no funcionarán con la opción de entropía alta. Si es necesario, puede deshabilitar la entropía alta.

Opciones de configuración

No usar entropía alta: esta opción deshabilita el uso de ASLR de alta entropía, que agrega 24 bits de entropía (1 TB de varianza) a la asignación de abajo a arriba para aplicaciones de 64 bits.

Nota:

La aleatorización de asignaciones de memoria (ASLR de abajo a arriba) no tiene modo de auditoría.

Simular la ejecución (SimExec)

Descripción

Simular la ejecución (SimExec) es una mitigación solo para aplicaciones de 32 bits. Esto ayuda a validar que las llamadas a LAS API confidenciales vuelvan a las funciones legítimas del autor de la llamada. Para ello, intercepta llamadas en API confidenciales y, a continuación, simula la ejecución de esas API recorriendo las instrucciones codificadas del lenguaje de ensamblado en busca de la instrucción RET, que debe volver al autor de la llamada. A continuación, inspecciona esa función y retrocede en la memoria para buscar la instrucción CALL anterior para determinar si la función y la instrucción CALL coinciden, y que el RET no se ha interceptado.

Las API interceptadas por esta mitigación son:

LoadLibraryA
LoadLibraryW
LoadLibraryExA
LoadLibraryExW
LdrLoadDll
VirtualAlloc
VirtualAllocEx
NtAllocateVirtualMemory
VirtualProtect
VirtualProtectEx
NtProtectVirtualMemory
HeapCreate
RtlCreateHeap
CreateProcessA
CreateProcessW
CreateProcessInternalA
CreateProcessInternalW
NtCreateUserProcess
NtCreateProcess
NtCreateProcessEx
CreateRemoteThread
CreateRemoteThreadEx
NtCreateThreadEx
WriteProcessMemory
NtWriteVirtualMemory
WinExec
CreateFileMappingA
CreateFileMappingW
CreateFileMappingNumaW
NtCreateSection
MapViewOfFile
MapViewOfFileEx
MapViewOfFileFromApp
LdrGetProcedureAddressForCaller

Si se detecta un gadget ROP, se finaliza el proceso.

Consideraciones de compatibilidad

Las aplicaciones que realizan la interceptación de API, especialmente el software de seguridad, pueden causar problemas de compatibilidad con esta mitigación.

Esta mitigación no es compatible con la mitigación de protección de código arbitraria.

Opciones de configuración

Validar la invocación de la API (CallerCheck)

Descripción

La validación de la invocación de API (CallerCheck) es una mitigación frente a las técnicas de programación orientada al retorno (ROP) que comprueba que las API sensibles hayan sido llamadas desde un origen válido. Esta mitigación inspecciona la dirección de retorno proporcionada y, a continuación, desensambla heurísticamente el código hacia atrás para localizar una llamada anterior a la dirección de retorno y determinar si el destino de la llamada coincide con el parámetro pasado a la función.

Las API interceptadas por esta mitigación son:

LoadLibraryA
LoadLibraryW
LoadLibraryExA
LoadLibraryExW
LdrLoadDll
VirtualAlloc
VirtualAllocEx
NtAllocateVirtualMemory
VirtualProtect
VirtualProtectEx
NtProtectVirtualMemory
HeapCreate
RtlCreateHeap
CreateProcessA
CreateProcessW
CreateProcessInternalA
CreateProcessInternalW
NtCreateUserProcess
NtCreateProcess
NtCreateProcessEx
CreateRemoteThread
CreateRemoteThreadEx
NtCreateThreadEx
WriteProcessMemory
NtWriteVirtualMemory
WinExec
CreateFileMappingA
CreateFileMappingW
CreateFileMappingNumaW
NtCreateSection
MapViewOfFile
MapViewOfFileEx
MapViewOfFileFromApp
LdrGetProcedureAddressForCaller

Si se detecta un gadget ROP, se finaliza el proceso.

Consideraciones de compatibilidad

Las aplicaciones que realizan la interceptación de API, especialmente el software de seguridad, pueden causar problemas de compatibilidad con esta mitigación.

Esta mitigación no es compatible con la mitigación de protección de código arbitraria.

Opciones de configuración

Validar cadenas de excepción (SEHOP)

Descripción

La validación de cadenas de excepciones (SEHOP) es una mitigación contra la técnica de explotación de sobrescritura del controlador de excepciones estructuradas (SEH). El control estructurado de excepciones es el proceso por el que una aplicación puede pedir que controle una excepción determinada. Los controladores de excepciones se encadenan juntos, por lo que si un controlador de excepciones decide no controlar una excepción determinada, se puede pasar al siguiente controlador de excepciones de la cadena hasta que uno decida controlarla. Dado que la lista de controladores es dinámica, se almacena en la pila. Un atacante puede usar una vulnerabilidad de desbordamiento de pila para sobrescribir el controlador de excepciones con un puntero al código que elija el atacante.

Esta mitigación se basa en el diseño de SEH, donde cada entrada SEH contiene un puntero al controlador de excepciones y un puntero al siguiente controlador de la cadena de excepciones. Esta mitigación es llamada por el despachador de excepciones, que valida la cadena SEH cuando se invoca una excepción. Comprueba que:

Todos los registros de la cadena de excepciones están dentro de los límites de la pila
Todos los registros de excepción están alineados
No hay punteros de controlador de excepciones que apunten a la pila
No hay punteros hacia atrás
La cadena de excepciones finaliza en un controlador de excepciones final conocido

Si se produce un error en estas validaciones, se anula el control de excepciones y no se controlará la excepción.

Consideraciones de compatibilidad

Los problemas de compatibilidad con SEHOP son relativamente poco frecuentes. No es habitual que una aplicación dependa de corromper la cadena de excepciones. Sin embargo, algunas aplicaciones se ven afectadas por los cambios sutiles en el tiempo, que podrían manifestarse como una condición de carrera que revela un error latente de varios subprocesos en la aplicación.

Opciones de configuración

Nota:

Validar cadenas de excepción (SEHOP) no tiene modo de auditoría.

Validar el uso del identificador

Descripción

Validar el uso del identificador es una mitigación que ayuda a protegerse contra un atacante mediante un identificador existente para acceder a un objeto protegido. Un descriptor es una referencia a un objeto protegido. Si el código de la aplicación hace referencia a un descriptor no válido, podría indicar que un adversario está intentando usar un descriptor que había registrado previamente (pero del que el recuento de referencias de la aplicación no tendría constancia). Si la aplicación intenta usar un objeto no válido, en lugar de devolver simplemente null, la aplicación genera una excepción (STATUS_INVALID_HANDLE).

Esta mitigación se aplica automáticamente a las aplicaciones de la Tienda Windows.

Consideraciones de compatibilidad

Las aplicaciones que no realizaban un seguimiento preciso de las referencias de control y que no ajustaban estas operaciones en controladores de excepciones podrían verse afectadas por esta mitigación.

Opciones de configuración

Nota:

Validar el uso del identificador no tiene modo de auditoría.

Validar la integridad del heap

Descripción

La mitigación de validación de la integridad del montón aumenta el nivel de protección de las mitigaciones de montón en Windows, ya que hace que la aplicación finalice si se detectan daños en el montón. Las mitigaciones incluyen:

Impedir que se libere un identificador HEAP
Ejecutar otra validación en encabezados de bloque extendidos para asignaciones de montón
Comprobación de que las asignaciones de montón aún no están marcadas como en uso
Añadir páginas de protección a las asignaciones grandes, los segmentos del montículo y los subsegmentos que superen un tamaño mínimo

Consideraciones de compatibilidad

Esta mitigación ya se aplica de forma predeterminada para las aplicaciones de 64 bits y para las aplicaciones de 32 bits destinadas a Windows Vista o posterior. Las aplicaciones heredadas de Windows XP o versiones anteriores están más en riesgo, aunque los problemas de compatibilidad son poco frecuentes.

Opciones de configuración

Nota:

Validar la integridad del montón no tiene modo de auditoría.

Validar la integridad de la dependencia de imagen

Descripción

La mitigación de dependencias de validación de imágenes ayuda a protegerse frente a ataques que intentan sustituir el código por archivos DLL vinculados estáticamente por binarios de Windows. La técnica de plantación de DLL abusa del mecanismo de búsqueda del cargador para inyectar código malicioso, lo que puede utilizarse para ejecutar código malicioso con privilegios elevados. Cuando el cargador carga un binario firmado por Windows y, a continuación, carga los archivos DLL de los que depende el binario, estos archivos binarios se comprueban para asegurarse de que también están firmados digitalmente como un binario de Windows. Si no superan la comprobación de firma, el archivo DLL no se cargará y se generará una excepción, devolviendo el estado STATUS_INVALID_IMAGE_HASH.

Consideraciones de compatibilidad

Los problemas de compatibilidad son poco comunes. Las aplicaciones que dependen de reemplazar archivos binarios de Windows por versiones privadas locales se ven afectadas y también hay un pequeño riesgo de revelar errores de temporización sutiles en aplicaciones multiproceso.

Opciones de configuración

Validar la integridad de la pila (StackPivot)

Descripción

La mitigación de validación de la integridad de la pila (StackPivot) ayuda a proteger contra el ataque Stack Pivot, un ataque ROP en el que un atacante crea una pila falsa en la memoria del montón y, a continuación, hace que la aplicación vuelva a la pila falsa que controla el flujo de ejecución.

Esta mitigación intercepta muchas API de Windows e inspecciona el valor del puntero de pila. Si la dirección del puntero de pila no se encuentra entre la parte inferior y la parte superior de la pila, se registra un evento y, si no está en modo de auditoría, se finaliza el proceso.

Las API interceptadas por esta mitigación son:

LoadLibraryA
LoadLibraryW
LoadLibraryExA
LoadLibraryExW
LdrLoadDll
VirtualAlloc
VirtualAllocEx
NtAllocateVirtualMemory
VirtualProtect
VirtualProtectEx
NtProtectVirtualMemory
HeapCreate
RtlCreateHeap
CreateProcessA
CreateProcessW
CreateProcessInternalA
CreateProcessInternalW
NtCreateUserProcess
NtCreateProcess
NtCreateProcessEx
CreateRemoteThread
CreateRemoteThreadEx
NtCreateThreadEx
WriteProcessMemory
NtWriteVirtualMemory
WinExec
CreateFileMappingA
CreateFileMappingW
CreateFileMappingNumaW
NtCreateSection
MapViewOfFile
MapViewOfFileEx
MapViewOfFileFromApp
LdrGetProcedureAddressForCaller

Consideraciones de compatibilidad

Las aplicaciones que usan pilas falsas se ven afectadas y también hay un pequeño riesgo de revelar errores de tiempo sutiles en aplicaciones multiproceso. Las aplicaciones que realizan la interceptación de API, especialmente el software de seguridad, pueden causar problemas de compatibilidad con esta mitigación.

Esta mitigación no es compatible con la mitigación de protección de código arbitraria.

Opciones de configuración

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-07-29