Proteggere il caricamento delle librerie per impedire gli attacchi di precaricamento delle DLL

Attacchi basati su LoadLibrary

Quando un'applicazione carica dinamicamente una DLL senza specificare un percorso completo, Windows prova a individuare tale DLL effettuando una ricerca lineare in un set di directory ben definito, noto come Ordine di ricerca DLL. Se Windows individua la DLL nell'ordine di ricerca della DLL, la carica. Tuttavia, se Windows non trova la DLL in una delle directory nell'ordine di ricerca della DLL, restituirà un errore nell'operazione di caricamento della DLL. Di seguito è riportato l'ordine di ricerca DLL per le funzioni LoadLibrarye LoadLibraryEx,che vengono usate per caricare dinamicamente le DLL:

1. La directory da cui è stata caricata l'applicazione

2. Directory di sistema

3. Directory di sistema a 16 bit

4. Directory di Windows

5. La directory di lavoro corrente

6. Directory elencate nella variabile di ambiente PATH

Si consideri lo scenario seguente:

• Un'applicazione carica una DLL senza specificare un percorso completo che prevede di trovare nel file CWD dell'applicazione.

• L'applicazione è completamente preparata a gestire il caso quando non trova la DLL.

• L'utente malintenzionato riconosce queste informazioni sull'applicazione e controlla il sito Web part.

• L'utente malintenzionato copia la propria versione appositamente realizzato della DLL nel file CWD. Si presuppone che l'utente malintenzionato abbia l'autorizzazione per eseguire questa operazione.

• Windows cerca nelle directory nell'ordine di ricerca della DLL e trova la DLL nel file CWD dell'applicazione.

In questo scenario, la DLL appositamente realizzato viene eseguita all'interno dell'applicazione e acquisisce i privilegi dell'utente corrente.

Consiglio Per evitare questo attacco, le applicazioni possono rimuovere la directory di lavoro corrente (CWD) dal percorso di ricerca dll chiamando
l'API SetDllDirectory usando una stringa vuota
(""). Se un'applicazione dipende dal caricamento di una DLL dalla directory corrente, ottenere la directory di lavoro corrente e usarla per passare un percorso completo di LoadLibrary.



Siamo anche consapevoli che alcuni sviluppatori usano LoadLibrary per verificare se una DLL specifica è presente per determinare quale versione di Windows viene eseguita dall'utente. Tenere presente che questo potrebbe rendere vulnerabile l'applicazione. Se la raccolta interessata non esiste effettivamente nella versione di Windows in cui l'applicazione è eseguita, un utente malintenzionato potrebbe introdurre in CWD una raccolta con lo stesso nome. Questa tecnica è sconsigliata. Usare invece le tecniche consigliate descritte nell'articolo in MSDN "Ottenere la versione del sistema".

Un'applicazione che carica plug-in di terze parti e che non può forzare i plug-in a usare un percorso qualificato per le chiamate LoadLibrary deve chiamare SetDllDirectory("") per rimuovere CWD e quindi chiamare SetDllDirectory("percorso di installazione del plug-in") per aggiungere la directory di installazione del plug-in al percorso di ricerca DLL.

Attacchi basati su SearchPath

Un attacco simile si verifica quando un'applicazione usa l'API SearchPath per individuare una DLL e caricare dinamicamente il percorso restituito da SearchPath. Di seguito è riportato l'ordine di ricerca predefinito per l'API SearchPath:

• La directory da cui è stata caricata l'applicazione

• La directory di lavoro corrente

• Directory di sistema

• Directory di sistema a 16 bit

• Directory di Windows

• Directory elencate nella variabile di ambiente PATH

Questo modello non è consigliato perché non è sicuro. Non è consigliabile usare la funzione SearchPath come metodo per l'individuazione di un file DLL se l'uso previsto dell'output si trova in una chiamata alla funzione LoadLibrary. Questo può causare l'individuazione del file DLL errato perché l'ordine di ricerca della funzione SearchPath è diverso dall'ordine di ricerca usato dalla funzione LoadLibrary. Se è necessario individuare e caricare un file DLL, usare la funzione LoadLibrary.

ShellExecute e CreateProcess

Le varianti di questi problemi possono verificarsi anche quando gli sviluppatori chiamano funzioni simili come ShellExecutee CreateProcessper caricare eseguibili esterni. È consigliabile prestare attenzione agli sviluppatori durante il caricamento dei file binari e specificare il percorso completo. Questo dovrebbe presentare una minore complessità quando si carica un file binario invece di una raccolta.

Indicazioni sull'identificazione dei caricamenti di raccolta non sicuri

Nel codice sorgente gli esempi seguenti sono relativi al caricamento di librerie non sicure:

• Nell'esempio di codice seguente l'applicazione cerca "schannel.dll" usando il percorso di ricerca meno sicuro. Se un utente malintenzionato può inserire schannel.dll contenuto in CWD, verrà caricato anche prima che l'applicazione esequie nelle directory di Windows la raccolta appropriata.

  DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
  HMODULE handle = LoadLibrary(result);

• Nell'esempio di codice seguente l'applicazione prova a caricare la libreria dalle varie posizioni dell'applicazione e del sistema operativo descritte all'inizio del documento per la chiamata LoadLibrary(). Se esiste il rischio che il file non sia presente, l'applicazione può provare a caricare il file dalla directory di lavoro corrente. Questo scenario è leggermente meno pericoloso rispetto all'esempio precedente. Tuttavia, espone comunque l'utente dell'applicazione a rischi se l'ambiente non è del tutto prevedibile.

  HMODULE handle = LoadLibrary("schannel.dll");

Di seguito sono riportati alcuni esempi di caricamento di raccolta più sicuro e migliore:

• Nell'esempio di codice seguente la raccolta viene caricata direttamente usando un percorso completo. L'utente malintenzionato non rischia di introdurre codice dannoso, a meno che non abbia già le autorizzazioni di scrittura per la directory di destinazione dell'applicazione.
  
  

  HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");

  
  
  Nota Per informazioni su come determinare la directory di sistema, vedere le risorse seguenti:
  
  GetSystemDirectory

  http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetKnownFolderPath

  http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

• Nell'esempio di codice seguente la directory di lavoro corrente viene rimossa dal percorso di ricerca prima di chiamare LoadLibrary. In questo modo il rischio si riduce in modo significativo, perché l'utente malintenzionato dovrebbe controllare la directory dell'applicazione, la directory di Windows o tutte le directory specificate nel percorso dell'utente per usare un attacco con precaricamento delle DLL.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");

• In tutti i sistemi che hanno installato l'aggiornamento della sicurezza 963027 (descritto in MS09-014),il codice seguente sposterà definitivamente CWD nell'ultimo punto dell'ordine di ricerca. Le chiamate successive alla funzione SetSearchPathMode dall'interno del processo che provano a cambiare la modalità di ricerca non verranno effettuate.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");
  

• Nell'esempio di codice seguente la directory di lavoro corrente viene rimossa dal percorso di ricerca prima di chiamare LoadLibrary. In questo modo il rischio si riduce in modo significativo, perché l'utente malintenzionato dovrebbe controllare la directory dell'applicazione, la directory di Windows o tutte le directory specificate nel percorso dell'utente per usare un attacco con precaricamento delle DLL.

  SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );
  HMODULE handle = LoadLibrary("schannel.dll");