Firma del codice in memoria

2

Poiché un sacco di codice malevolo è in esecuzione solo in memoria, non sarebbe possibile firmare ogni codice eXecutable (funzioni ecc.) di ciascun file PE e controllare prima di ogni nuovo thread avviato il codice (in memoria) davvero firmato per continuare?

Con questo sistema, se un processo firmato vuole iniettare parte del suo codice in un altro processo (tramite VirtualAllocEx, WriteProcessMemory ecc.) andrà bene.

Quali sono i difetti del mio ragionamento? Questo meccanismo può essere utilizzato nella pratica (con qualche cambiamento nella struttura PE o nel sistema operativo)?

Ed; Ometto intenzionalmente i linguaggi di scripting e la funzione "in-memory signed code" che propongo è ovviamente da utilizzare in aggiunta a funzionalità come Windows Guard / AppLocker

    
posta cialeaks 23.03.2017 - 21:27
fonte

1 risposta

1

Se un utente malintenzionato ha una vulnerabilità di scrittura arbitraria, può ignorare qualsiasi forma di firma del codice in memoria implementata dal software. Potrebbero modificare la memoria dopo che il codice è stato verificato ma prima che venga eseguito (una classica vulnerabilità TOCTOU), o semplicemente commutare qualsiasi bit usato per verificare l'integrità. L'unico modo in cui ciò potrebbe funzionare è se il controllo è stato implementato in hardware, con il codice effettivo verificato dalla CPU stessa. Tuttavia, è molto più semplice utilizzare semplicemente i controlli di accesso standard per evitare l'iniezione di memoria. Su Linux, ad esempio, questo può essere fatto con Yama LSM. Questo è possibile perché l'iniezione di memoria è mediata dal kernel. Il processo di iniezione deve specificare il target e richiedere il permesso di leggere o scrivere nella sua memoria. Il kernel può semplicemente rifiutare la richiesta, forzando il processo dannoso ad aumentare i privilegi un po 'per modificare la memoria.

    
risposta data 31.12.2017 - 05:30
fonte

Leggi altre domande sui tag