DepTest permite comprobar de forma independiente el estado de la prevención de ejecución de datos (DEP) de Windows® para verificar si esta función de prevención de intrusiones está realmente habilitada y protege todos los procesos y servicios en ejecución. Puede consultar, por ejemplo, este debate. La instalación de EMET de Microsoft también puede ayudar a examinar la configuración del sistema. Encontrará más información sobre por qué recomendamos habilitar AlwaysOn y sobre el funcionamiento interno de DepTest en este debate de Wilder Security.
La herramienta se desarrolló alrededor de 2002, al mismo tiempo que Sys-Manage BufferShield, para demostrar que la prevención de ejecución de datos basada en software de Microsoft solo protegía frente a un exploit concreto, ocurrido una sola vez, que sobrescribía el puntero al controlador de excepciones SEH. Dar a esta función de software un nombre similar al de la protección NX por hardware confundía a los clientes y generaba una falsa sensación de seguridad. También mostró que Comodo Memory Guard (retirado poco después) no detenía eficazmente los desbordamientos de búfer porque utilizaba un enfoque en modo de usuario (interceptación de las API de Windows) en lugar de un controlador a nivel de kernel. Al principio afirmaron en sus foros que nuestra prueba solo ejecutaba una instrucción NOP. Después utilizamos código shell real para crear un archivo, omitiendo la API de Windows e invocando directamente la API NtCreateFile del kernel mediante el mecanismo de puerta de llamada. Hay otras formas de omitir la API de Windows y eludir esa protección mediante código shell. [¡Seguimos apreciando los certificados de Comodo!]
Ya no mantenemos ni desarrollamos BufferShield para versiones de Windows posteriores a Windows XP y Server 2003, porque esos sistemas operativos incluyen protección NX y ASLR. Solo hay que habilitarlas correctamente. Los procesadores modernos también incorporan NX por hardware (o XD en el caso de AMD), por lo que ya no es necesario adaptarlo a sistemas operativos más recientes, que tampoco funcionarían de forma eficiente en procesadores tan antiguos.
Si la prueba falla en su equipo, ejecute el siguiente comando en una consola con privilegios de administrador de Windows Vista o posterior para habilitar NX (Intel) o XD (AMD). Después reinicie el equipo y repita la prueba:
bcdedit /set nx AlwaysOn
Esto habilita la protección frente a desbordamientos de búfer para todas las aplicaciones y servicios, y no solo para el sistema operativo. También impide que el código shell utilice el método denominado return-to-libc para desactivar NX/XD si ASLR falla o está comprometido. Si alguna aplicación de terceros presenta problemas de compatibilidad, intente actualizarla o póngase en contacto con su fabricante. Después de más de 15 años, debería ser sabido que no es buena práctica ejecutar código desde páginas de memoria no marcadas para ejecución.
Puede volver a la configuración predeterminada ejecutando el siguiente comando en una consola con privilegios de administrador:
bcdedit /set nx OptIn