Considérations relatives à la sécurité dans l'API de débogage
Les considérations de sécurité sur l'utilisation de l'API de débogage CLR (Common Language Runtime) sont comme suit :
Attachement à un processus. Sur Windows NT et Windows 2000, le processus du programme débogué doit être créé avec un descripteur de sécurité qui accorde l'accès complet de débogueur. Le processus de débogage doit avoir l'autorisation SE_DEBUG_NAME et être activé pour déboguer tout processus. Cette autorisation est accordée par défaut à un administrateur Windows NT ou Windows 2000. Windows 95, Windows 98 et Windows CE ne fournissent pas ce niveau de sécurité car ils n'imposent pas de spécifications particulières pour l'attachement à un processus.
Injection de code Dynamique. Un assembly est vérifié quand il est chargé. Pendant l'injection de code dynamique, le débogueur modifie une partie du code et envoie le fichier exécutable portable delta dans le processus du programme débogué. Le fichier exécutable portable delta n'est pas vérifié. Les méthodes mises à jour sont vérifiées après leur compilation par le compilateur juste-à-temps (JIT). Pour plus d'informations sur l'injection de code dynamique, consultez Injection dynamique du code avec l'API de débogage.
Modification des métadonnées d'un assembly signé. L'intégrité d'un assembly est vérifiée et les autorisations correctes sont accordées uniquement lorsqu'un assembly signé est chargé. Si un débogueur modifie le code en cours en changeant les métadonnées qui sont associées au programme débogué, cette opération modifie le hachage qui calcule la signature de l'assembly. L'opération n'entraîne pas de vérifications de sécurité supplémentaires. Les autorisations qui ont été assignées par le runtime sont encore valides.
Débogage d'un processus hostile. N'utilisez pas l'API de débogage pour déboguer un processus potentiellement hostile, pour deux raisons majeures. La première c'est que l'infrastructure de débogage n'est pas immunisée contre les processus réalisés intelligemment pour exploiter des vulnérabilités. La seconde c'est que l'arrêt d'un processus pendant le débogage Managé uniquement peut impliquer un dérapage avant l'arrêt réel. Par conséquent, il n'y a aucune garantie qu'une ligne de code donnée ne s'exécutera pas.
Voir aussi
Concepts
Vue d'ensemble du débogage CLR