Sembra che ci siano nuvole all’orizzonte. Sembra sia stata scoperta un’altra falla 0day in Windows dopo l’ultima relativa a Windows Shell e sistemata da Microsoft proprio durante questo mese.

Un nuova falla insomma, o almeno è quello che si può leggere da alcuni articoli che stanno diffondendosi velocemente nel web.

Da quello che si può leggere, questa vulnerabilità permette di eseguire arbitrariamente del codice forzando alcune applicazioni a caricare dei file nocivi. Non sono al momento a conoscenza di ulteriori dettagli sulla falla, e sembra che la società Rapid7 rilascerà ulteriori dettagli durante questa settimana. Così il massimo che possiamo fare è fantasticare un po.

L’articolo di ComputerWorld ricorda che Apple iTunes era vulnerabile a questa falla, che è stata successivamente corretta da Apple. Basta leggere il bollettino di sicurezza Apple per capire che forse questo tipo di attacco 0day non è poi così nuovo.

Il bollettino di sicurezza Apple riporta:

A path searching issue exists in iTunes. iTunes will search for a specific DLL in the current working directory. If someone places a maliciously crafted file with a specific name in a directory, opening another file in that directory in iTunes may lead to arbitrary code execution. This issue is addressed by removing the code that uses the DLL

Questo mi ricorda così tanto un vecchissimo trucco per iniettare codice all’interno di un’applicazione, conosciuto ormai da svariati anni. La parola chiave di tutto ciò è: Dynamic-Link Library Search Order.

Di cosa stiamo parlando? Quando un’applicazione prova a caricare in memoria uno specifico modulo, utilizza solitamente l’API di Windows LoadLibrary / LoadLibraryEx – almeno se si vuole seguire la modalità documentata da Microsoft.

Uno dei parametri accettati dall’API è il percorso al modulo richiesto. Se il programmatore non specifica in maniera esplicita tutto il percorso al modulo bensì solo il nome del modulo, il sistema operativo inizierà a cercare il suddetto modulo in una serie di percorsi già prestabiliti.

La lista di questi percorsi già prestabiliti è chiamata Dynamic-Link Library Search Order ed è esplicitamente documentata nell’MSDN di Microsoft. Questa lista dipende dalle configurazioni del sistema operativo. Tuttavia, la configurazione standard è:

  • The directory from which the application loaded.
  • The system directory. Use the GetSystemDirectory function to get the path of this directory.
  • The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  • The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
  • The current directory.
  • The directories that are listed in the PATH environment variable.

Quindi, se l’applicazione sta tentando di caricare un modulo specificandone solo il nome, il sistema operativo prima di tutto verificherà se si tratta di un modulo già conosciuto (sono elencati nella chiave di registro KnownDLLs). Se non lo è, inizierà la ricerca in ognuno dei percorsi sopra elencati uno ad uno.

Ad esempio, se il modulo viene trovato subito all’interno della directory da dove l’applicazione è eseguita, Windows interrompe la ricerca e carica questo modulo.

Ora tutto diventa più chiaro, e le possibili vie per sfruttare questo trucco sono molte, soprattutto se si pensa ad un pirata informatico.

Sebbene l’implementazione di questo ordine possa essere oggetto di dubbi e domande, non penso che questa “falla” sia un problema di Windows. La logica dietro il caricamento dei moduli a runtime è ben documentata e spiegata all’interno dell’MSDN. Inoltre, sia l’ordine di ricerca che il funzionamento delle API LoadLibrary/LoadLibraryEx sono ben documentate. Diventa dunque un problema relativo agli sviluppatori, se hanno deciso di seguire le linee guida di sviluppo illustrate da Microsoft o meno. In realtà questo ambiguo comportamento di Windows è sfruttato ormai da anni dai malware ed è oggetto di discussioni online da molto tempo.

Non si sa se la falla discussa sia proprio questa, quello che si può dire è che in caso si tratterebbe di una vecchia-nuova falla 0day.