Perché alcune DLL non sono randomizzate? Cosa rende difficile la distribuzione completa di ASLR per tutte le DLL?

11

Una delle sfide con la distribuzione di ASLR è che, almeno su Windows, alcune DLL (librerie) non sono compilate in modo compatibile con ASLR. (Non sono compilati come codice indipendente dalla posizione, quindi il punto in cui vengono caricati in memoria non può essere randomizzato.)

Questo è problematico, perché se un'applicazione carica anche solo una DLL non randomizzata, allora non è effettivamente randomizzata. Per interrompere gli attacchi standard (ad esempio gli attacchi ROP), tutto il codice deve essere randomizzato : anche una singola DLL non randomizzata è sufficiente per supportare gli attacchi ROP. Quindi, per un'approssimazione del primo ordine, ASLR è utile solo per proteggere una particolare applicazione se tutte delle sue DLL sono randomizzate. Le applicazioni spesso caricano molte DLL e, poiché tutto ciò che serve è una DLL non randomizzata, ciò rende particolarmente importante assicurarsi che tutte le DLL siano randomizzate.

In generale, l'industria si sta muovendo verso un maggiore uso della randomizzazione, ma lentamente : Immagino che ci vorrà del tempo per portare questo ad ogni DLL che qualsiasi programma userà mai. Ad esempio, è stato recentemente rivelato che la DLL di Dropbox non usa la randomizzazione , quindi qualsiasi programma che utilizza la DLL Dropbox non è protetto dagli attacchi ROP (qualsiasi programma che utilizza la DLL Dropbox perde il vantaggio dell'ASLR).

La mia domanda: quali sono i motivi tipici per cui alcune DLL non sono randomizzate? Si tratta in genere di una sorta di barriera tecnica o di un problema tecnico che rende difficile o impossibile compilare la DLL come codice indipendente dalla posizione? È la mancanza di consapevolezza / attenzione alla sicurezza, da parte degli sviluppatori che costruiscono la DLL? Sono legacy DLL che sono molto vecchie e non sono state ricompilate per trarre vantaggio dalla randomizzazione? Microsoft Visual C ++ non riesce a fare la cosa giusta per impostazione predefinita (non riesce a compilare DLL come codice indipendente dalla posizione per impostazione predefinita)? È qualcosa di completamente diverso?

Esistono miglioramenti tecnici o strumenti che potrebbero facilitare una maggiore distribuzione di ASLR / randomizzazione per DLL che attualmente non supportano la randomizzazione?

Risorse correlate: SlopFinder è uno strumento per eseguire la scansione del sistema per DLL che non supportano l'ASLR.

    
posta D.W. 11.09.2013 - 21:51
fonte

1 risposta

8

Ci sono alcune buone informazioni qui . Apparentemente, una DLL può essere soggetta ad ASLR solo se è contrassegnata come tale, a causa di "problemi di compatibilità con le versioni precedenti". Sebbene una DLL sia, per sua natura, destinata a essere trasferita, posso immaginare che alcuni software (scarsamente) scritti possano fare alcuni trucchi che si basano sulla DLL finendo in un intervallo relativamente ristretto dello spazio degli indirizzi (un possibile candidato potrebbe essere Garbage Collector che deve distinguere tra "puntatori ai dati" e "puntatori al codice" - Lo so che tali problemi si sono verificati con alcune versioni dell'interprete Javascript di Chrome quando sono stati avviati su OpenBSD con l'emulazione Linux).

Se Microsoft si è presa la briga di implementare un flag aggiuntivo, allora è plausibile, se non probabile, che abbiano riscontrato almeno un caso di tale software che non potevano ignorare (la compatibilità con le versioni precedenti è molto importante nel mondo Windows) .

Quindi la DLL consentirà che l'ASLR si verifichi se il linker statico lo ha detto, quando la DLL è stata creata l'ultima volta. Si tratta di utilizzare il flag /DYNAMICBASE . La documentazione afferma che:

By default, /DYNAMICBASE is on.

Le documentazioni per Visual Studio 2010 e 2012 contengono questa frase, ma NON la documentazione per Visual Studio 2008. Quindi si deve presumere che la maggior parte delle persone che usano Visual Studio 2010+ produca DLL compatibili con ASLR, ma la maggior parte delle persone che usano Visual Studio 2008 o una versione precedente producono DLL che sono non soggette ad ASLR.

Nella prima pagina linkò sopra, uno dei commenti dice:

You can still use the Microsoft linker to do that, after your PE image is built. Use link /edit /dynamicbase (or editbin /dynamicbase ).

Quindi puoi "aggiustare" una DLL, ma supponendo che la DLL non si romperà con ASLR, cioè la mancanza di flag era dovuta alla configurazione predefinita di Visual Studio, usata dal fornitore della DLL.

    
risposta data 11.09.2013 - 22:13
fonte

Leggi altre domande sui tag