Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las consideraciones de la seguridad para utilizar la API de depuración de Common Language Runtime (CLR) son las siguientes:
Asociación a un proceso. En Windows NT y Windows 2000, el proceso del código que está siendo depurado se debe crear con un descriptor de seguridad que permita el acceso total del depurador. El proceso de depuración debe tener el permiso SE_DEBUG_NAME concedido y habilitado para depurar cualquier proceso. Un administrador de Windows NT o Windows 2000 tiene concedido este permiso de forma predeterminada. Windows 95, Windows 98 y Windows CE no proporcionan este nivel de seguridad porque no imponen requisitos especiales para la asociación a un proceso.
Inyección dinámica de código. Un ensamblado se comprueba cuando se carga. Durante la inyección de código dinámica, el depurador modifica parte del código y envía un archivo ejecutable portable (PE) delta al proceso del código que está siendo depurado. El PE delta no se comprueba. Los métodos actualizados se comprueban una vez compilados por el compilador Just-In-Time (JIT). Para obtener más información acerca de la inserción dinámica de código, consulte Insertar código dinámicamente con la API de depuración.
Modificación de los metadatos de un ensamblado firmado. La integridad de un ensamblado se comprueba y los permisos correctos se conceden solamente después de cargar un ensamblado firmado. Si un depurador modifica el código en ejecución cambiando los metadatos que se asocian al código que está siendo depurado, esta operación cambia el hash que calcula la firma del ensamblado. La operación no provoca comprobaciones de seguridad adicionales. Los permisos asignados por el motor en tiempo de ejecución continúan siendo válidos.
Depuración de un proceso hostil. Hay dos razones principales para no utilizar la API de depuración para depurar un proceso potencialmente hostil. Primero, la infraestructura de depuración no es inmune a procesos sofisticados creados para aprovecharse de las vulnerabilidades. Segundo, detener un proceso durante la depuración exclusivamente administrada puede implicar alguna posposición antes de la pausa real. No hay, por consiguiente, ninguna garantía que una línea determinada de código no se ejecute.
Vea también
Conceptos
Información general sobre la depuración en CLR