hit counter
Microsoft Security Advisory 2269637 sul caricamento non sicuro delle DLL - NonSoloSecurity Blog di Feliciano Intini - Site Home - TechNet Blogs

NonSoloSecurity Blog di Feliciano Intini

Notizie, best practice, strategie ed innovazioni di Sicurezza (e non solo) su tecnologia Microsoft

Microsoft Security Advisory 2269637 sul caricamento non sicuro delle DLL

Microsoft Security Advisory 2269637 sul caricamento non sicuro delle DLL

  • Comments 7
  • Likes

[English readers: you can find English links in this post for your convenience]

Microsoft ha appena comunicato il rilascio di un nuovo Security Advisory per fornire le linee guida ufficiali di protezione in merito ad uno studio di ricerca pubblicato in questi giorni che illustra la possibilità di poter sfruttare alcune modalità non sicure di programmazione nel caricamento delle DLL per poter effettuare un attacco di tipo Remote Code Execution:

Microsoft Security Advisory (2269637) - Insecure Library Loading Could Allow Remote Code Execution

MSRC post: Microsoft Security Advisory 2269637 Released

SRD post: More information about the DLL Preloading remote attack vector

Questa tipologia di attacchi denominata "binary planting" o "DLL preloading attacks" non è di fatto nuova (è già documentata in un post di David Le Blanc del 2008), ed è possibile se l’applicazione non passa a Windows un percorso completo per la DLL che intende caricare. In questo caso Windows provvede a cercarla all’interno di una serie predefinita di cartelle (DLL Search Order): se chi attacca ha il controllo di una di queste posizioni e vi piazza una DLL pericolosa, e se il sistema non trova una DLL legittima prima di giungere alla cartella compromessa, si è in grado di far eseguire la DLL all’applicazione vulnerabile nel contesto di sicurezza dell’utente che l’ha lanciata.

Se da un lato non si tratta di una nuova tipologia di attacchi, è nuovo il vettore che è possibile usare per operare un attacco da remoto, secondo questa sequenza:

  1. chi attacca crea un file di dati da far aprire all’applicazione vulnerabile e crea una DLL pericolosa,
  2. le salva entrambe su una share di rete o WebDAV sotto il suo controllo
  3. convince l’utente ad aprire il file di dati che induce l’applicazione a caricare la DLL pericolosa.

Capite bene che qualsiasi applicazione che possa usare le modalità non sicure di caricamento delle DLL è potenzialmente vulnerabile a questa classe di attacchi e il suo fornitore deve provvedere a fissare il problema.

Il Security Advisory provvede a documentare la problematica e a fornire:

Il tool, da testare prima del suo utilizzo massiccio in produzione come si conviene per ogni aggiornamento che alteri il comportamento applicativo, può essere un’ottima soluzione temporanea in attesa che i diversi fornitori forniscano gli aggiornamenti per le applicazioni che si riveleranno vulnerabili.

Da parte sua Microsoft sta attivamente verificando se e quali delle sue applicazioni soffrano di questa problematica, e aggiornerà il Security Advisory con nuove informazioni quando saranno disponibili.

Feliciano

Other related posts/resources:

Comments
  • Ecco un'altro mega-buco dovuto all'insicurezza by-design di tutte le versioni di windows.

    L'ho sempre pensato che le DLL erano una grandissima schifezza, e ancor di più il registry...

    Bisogna voltare pagina, rifare da ZERO... quando?

    Prendete spunto da Apple, non nel marketing xche vedo che ci avete già pensato, ma nella struttura del loro sistema operativo. Hanno deciso di voltare pagina e l'hanno fatto, ora sono messi molto meglio...

  • @RealENNECI

    Certo che portare macosx come esempio in ambito sicurezza è davvero ridicolo...

  • @Tullio

    Scusa, potete parlare voi business man aka windows fanboys?

    Mi risulta che l'ambiente OSX sia decisamente messo meglio, soprattutto come architettura, che come licensing che come sicurezza... performances... usabilità.... ecc...

    Insomma... non ci sono paragoni...

  • @Tullio

    Don't feed the troll...

  • ma il valore da impostare per impedire questi attacchi è CWDIllegalInDllSearch = 2 oppure CWDIllegalInDllSearch = 0xFFFFFFFF ?

  • @gianni: se imposti 0xFFFFFFFF il caricamento dalla directory corrente viene disabilitato anche per il computer locale. Credo sia più conservativo impostare 2 per tutte le applicazioni

  • @RealEnneci

    vatti a vedere le falle critiche di esecuzione codice da remoto arbitrario che ha risolto Apple sul suo sistema "cassaforte" Osx da 10.6 a 10.6.4

    centinaia di vulnerabilita'  critiche di remote code execution ovvero bollettini da guerra  con pacchetti ogni mese  mezzo di Fix da scaricare dai 350Mbytes in su'. In pratica come un Service Pack di Microsoft Windows ogni mese e mezzo...un'agonia sia da scaricare per chi nn ha ADSL super ma connessioni Mobile 3g umts che a piu' di 1 Megabitt/sec effettivi non vanno..piu' il tempo per installare tutto quel ben di dio ogni volta e riavviare le macchine  ed ottimizzare il system

    Non parlate di sicurezza con paragoni se non sapete nulla di questi  argomenti ma soporattutto nn sapete cosa fa Apple ad ogni fix che rilascia circa ogni mese e mezzo per il suo OSx tanto sbandierato ai 4 venti come una cassaforte a base Unix ..

    marketing e solo marketing per chi non se ne intende  come voi certamente ma che parlate solo sul web senza sapere

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment