Considerazioni sulla sicurezza nell'API di debug
Di seguito vengono riportate alcune considerazioni sulla sicurezza per l'utilizzo dell'API di debug di Common Language Runtime:
Connessione a un processo. In Windows NT e Windows 2000, il processo dell'oggetto del debug deve essere creato mediante un descrittore di sicurezza che consenta al debugger l'accesso completo. Per il processo di debug è necessaria l'autorizzazione SE_DEBUG_NAME attivata, in modo da poter eseguire il debug di qualsiasi processo. Un amministratore di Windows NT o Windows 2000 dispone di questa autorizzazione per impostazione predefinita. Windows 95, Windows 98 e Windows CE non forniscono questo stesso livello di sicurezza perché non richiedono requisiti speciali per la connessione a un processo.
Inserimento di codice dinamico. Un assembly viene verificato nel momento in cui viene caricato. Durante l'inserimento di codice dinamico, il debugger modifica parte del codice e invia un file eseguibile di tipo PE delta nel processo dell'oggetto del debug. Il file di tipo PE delta non viene verificato. I metodi aggiornati vengono verificati dopo la compilazione tramite JIT. Per ulteriori informazioni sull'inserimento di codice dinamico, vedere Inserimento dinamico di codice con l'API di debug.
Modifica dei metadati di un assembly firmato. Viene verificata l'integrità di un assembly e vengono concesse le autorizzazioni appropriate solo quando un assembly firmato viene caricato. La modifica del codice in esecuzione da parte di un debugger che sostituisce i metadati associati all'oggetto del debug comporta la modifica dell'hash che calcola la firma dell'assembly. L'operazione non implica controlli di sicurezza aggiuntivi. Le autorizzazioni assegnate dal runtime continuano a essere valide.
Debug di un processo ostile. L'API di debug non deve essere utilizzata per eseguire il debug di un processo potenzialmente ostile principalmente per due motivi. Innanzitutto, l'infrastruttura di debug non è protetta da processi particolarmente elaborati che potrebbero sfruttarne le vulnerabilità. Inoltre, l'arresto di un processo durante il debug solo gestito può implicare uno slittamento prima dell'interruzione effettiva. Pertanto, non è possibile avere la certezza che una determinata riga di codice non verrà eseguita.