Security Considerations in the Debugging API
The security considerations for using the common language runtime (CLR) debugging API are as follows:
Attaching to a process. On Windows NT and Windows 2000, the debuggee process must be created with a security descriptor that grants the debugger full access. The debugging process must have the SE_DEBUG_NAME permission granted and enabled to debug any process. A Windows NT or Windows 2000 administrator is granted this permission by default. Windows 95, Windows 98, and Windows CE do not provide this level of security because they do not impose special requirements for attaching to a process.
Dynamic code injection. An assembly is verified when it is loaded. During dynamic code injection, the debugger modifies some code and sends a delta portable executable (PE) file into the debuggee process. The delta PE is not verified. The updated methods are verified after they are compiled by the just-in-time (JIT) compiler. For more information about dynamic code injection, see Injecting Code Dynamically with the Debugging API.
Modification of a signed assembly's metadata. The integrity of an assembly is checked and the correct permissions are granted only when a signed assembly is loaded. If a debugger modifies the running code by changing the metadata that is associated with the debuggee, this operation changes the hash that computes the assembly’s signature. The operation does not cause additional security checks. Permissions that were assigned by the runtime are still valid.
Debugging a hostile process. Do not use the debugging API to debug a potentially hostile process for two major reasons. First, the debugging infrastructure is not immune to cleverly crafted processes that might exploit vulnerabilities. Second, stopping a process during managed-only debugging can involve some slippage before the actual stop. Therefore, there is no guarantee that a given line of code will not execute.