Luca Annunziata

Falla DLL, Microsoft ora sa tutto

Confermata ufficialmente la vulnerabilità anticipata da HD Moore. Il problema era noto, ma ora cambiano le modalità con cui si può sfruttare. Disponibile un primo workaround, che però non risolve il problema

Roma - Con un advisory, Microsoft ha reso noto di essere a conoscenza della vulnerabilità DLL descritta la scorsa settimana da due differenti team di analisti di sicurezza. Redmond precisa che la vulnerabilità non riguarda specificamente un proprio prodotto, ma che l'advisory è stato diramato per portare a conoscenza del maggior numero di utenti e admin possibili del nuovo vettore d'attacco individuato e ora divulgato da quelli di Metasploit/Rapid7.

Secondo i tecnici di BigM, il problema del "binary planting" (ovvero del caricamento di librerie al volo, in questo caso DLL, contenenti payload pericolosi) è comune a molte piattaforme - viene citato UNIX. La differenza rispetto alla modalità classica, e meno pericolosa, di attacco in questo caso risiede nel metodo: in luogo del caricamento della DLL dalla memoria locale, l'utente può essere indotto a eseguire delle operazioni del tutto lecite avviando però il caricamento della libreria da una memoria condivisa e/o remota. Anche gli antivirus, in queste circostanze, potrebbero rivelarsi inefficaci.

La soluzione proposta, che Microsoft descrive come best practices, è quella di specificare in fase di programmazione il percorso preciso e non generico dove trovare la libreria: in questo modo, a meno di una sostituzione fisica di un file sul disco della vittima, non dovrebbe essere possibile far scambiare a un'applicazione una DLL illegittima per una legittima. In più, come suggerito da HD Moore e altri la scorsa settimana, viene caldeggiata l'ipotesi di disabilitare temporaneamente certi tipi di attività di rete (SMB, WebDAV) per impedire che il vettore di attacco resti attivo. Microsoft mette a disposizione un tool per semplificare il processo, ma si tratta evidentemente di una soluzione tampone che non risolve definitivamente il problema.
Da parte loro, quelli di Metasploit non sono stati con le mani in mano. Hanno contattato Microsoft per fornirgli le informazioni di cui disponevano, e hanno rilasciato un tool di audit (da caricare come modulo nella loro suite per i Pen Test) in grado di effettuare verifiche su qualunque applicativo potenzialmente affetto dalla vulnerabilità. Come detto, difficilmente questo tipo di attacco potrà essere vanificato da un aggiornamento di sistema: saranno i singoli vendor a dover pubblicare, se lo desiderano, un update del proprio software che risulti immune a questa minaccia.

Luca Annunziata
93 Commenti alla Notizia Falla DLL, Microsoft ora sa tutto
Ordina
  • Mi stanno bene tutti i problemi di sicurezza, ma il poter avere le mie belle dll nella directory in cui ho la mia applicazione ha un piccolo vantaggio.... posso disinstallare il programma cancellando tutti i file/la directory senza lasciare imput***ato il sistema... oppure posso usare una vecchia versione di qualche libreria non retrocompatibile (presente aggiornata in %windir%\system32 senza bloccare il funzionamento di altre applicazioni che richiedono una versione più recente della suddetta dll.

    Se un virus ha accesso in scrittura alla directory in cui è presente un eseguibile, potrà sì mettere una dll malevola, ma potrà anche modificare in modo malevolo l'exe.

    Il fatto di restringere/bloccare il caricamento di dll mi sembra tanto una falsa sicurezza (sempre IMHO)...
    non+autenticato
  • - Scritto da: Jack
    > Mi stanno bene tutti i problemi di sicurezza, ma
    > il poter avere le mie belle dll nella directory
    > in cui ho la mia applicazione ha un piccolo
    > vantaggio.... posso disinstallare il programma
    > cancellando tutti i file/la directory senza
    > lasciare imput***ato il sistema... oppure posso
    > usare una vecchia versione di qualche libreria
    > non retrocompatibile (presente aggiornata in
    > %windir%\system32 senza bloccare il funzionamento
    > di altre applicazioni che richiedono una versione
    > più recente della suddetta
    > dll.
    >
    > Se un virus ha accesso in scrittura alla
    > directory in cui è presente un eseguibile, potrà
    > sì mettere una dll malevola, ma potrà anche
    > modificare in modo malevolo
    > l'exe.
    >
    > Il fatto di restringere/bloccare il caricamento
    > di dll mi sembra tanto una falsa sicurezza
    > (sempre
    > IMHO)...

    Personalmente l' ho sempre creduto un falso bug
    Ma mi chiedo cosa succede in caso di eseguibili che vengono eseguiti con privilegi differenti.
    In unix i programmi suid non tengono conto di LD_LIBRARY_PATH
    In windows viene usata la dir. corrente anche per i programmi UAC ?
    Purtroppo non ho trovato niente su questo
    non+autenticato
  • - Scritto da: vintage
    > Personalmente l' ho sempre creduto un falso bug
    > Ma mi chiedo cosa succede in caso di eseguibili
    > che vengono eseguiti con privilegi
    > differenti.
    > In unix i programmi suid non tengono conto di
    > LD_LIBRARY_PATH
    > In windows viene usata la dir. corrente anche per
    > i programmi UAC
    > ?
    > Purtroppo non ho trovato niente su questo

    Non lo so, il fatto è che se un programma con privilegi limitati fa una chiamata ad una falsa kernel32.dll, suppongo (e spero) che questa kernel32.dll giri con privilegi limitati in un'altra istanza rispetto alla vera libreria, e che quindi le chiamate falliscano!

    Magari è questo il vero problema legato a quel bug, ma visto che non ho in mente l'acquisto di nuovo hardware, ho ancora il mio bell'XP e non intendo cambiarlo con seven per ora...
    non+autenticato
  • - Scritto da: Jack
    > - Scritto da: vintage
    > > Personalmente l' ho sempre creduto un falso
    > bug
    >
    > > Ma mi chiedo cosa succede in caso di eseguibili
    > > che vengono eseguiti con privilegi
    > > differenti.
    > > In unix i programmi suid non tengono conto di
    > > LD_LIBRARY_PATH
    > > In windows viene usata la dir. corrente anche
    > per
    > > i programmi UAC
    > > ?
    > > Purtroppo non ho trovato niente su questo
    >
    > Non lo so, il fatto è che se un programma con
    > privilegi limitati fa una chiamata ad una falsa
    > kernel32.dll, suppongo (e spero) che questa
    > kernel32.dll giri con privilegi limitati in
    > un'altra istanza rispetto alla vera libreria, e
    > che quindi le chiamate
    > falliscano!
    >
    Questo si spera che sia vero !!
    Ma il contrario ?
    Se eseguo un processo con privilegi diversi dall' utente corrente il kernel tiene conto della directory corrente e/o di quella in cui è posizionato l' exe oppure ricerca le dll solo nelle directory si sistema ?
    In unix un processo suid (che è qualcosa di equivalente) ricerca le librerie solo nelle dir. specificate in /etc/ld.so.conf e ignorando completamente quelle specificate in LD_LIBRARY_PATH



    > Magari è questo il vero problema legato a quel
    > bug, ma visto che non ho in mente l'acquisto di
    > nuovo hardware, ho ancora il mio bell'XP e non
    > intendo cambiarlo con seven per
    > ora...

    Il bug (se esiste) è presente anche in XP
    non+autenticato
  • - Scritto da: vintage
    > Se eseguo un processo con privilegi diversi dall'
    > utente corrente il kernel tiene conto della
    > directory corrente e/o di quella in cui è
    > posizionato l' exe oppure ricerca le dll solo
    > nelle directory si sistema?

    Per sfruttare questo bug (e portare a termine un exploit) la dll corrotta deve essere nella stessa directory dell'eseguibile o la directory corrente, in cui il "contagiatore" ha avuto modo di scrivere dato che gli altri percorsi di ricerca sono o dovrebbero essere protetti. Il programma deve poi essere eseguito con privilegi elevati dal sistema o dall'utente.

    Se il contagiatore ha avuto accesso in scrittura alla directory in questione, avrebbe però potuto modificare direttamente l'eseguibile per svolgere azioni dannose.

    Questo è il motivo che mi porta a pensare che sia un falso problema, nel senso che è come avere una porta ed una finestra aperte, bloccando la ricerca delle dll nel path corrente viene chiusa la finestra, ma la porta ovvero la modifica diretta dell'eseguibile, è sempre aperta....
    non+autenticato
  • - Scritto da: Jack
    > - Scritto da: vintage
    > > Se eseguo un processo con privilegi diversi
    > dall'
    > > utente corrente il kernel tiene conto della
    > > directory corrente e/o di quella in cui è
    > > posizionato l' exe oppure ricerca le dll solo
    > > nelle directory si sistema?
    >
    > Per sfruttare questo bug (e portare a termine un
    > exploit) la dll corrotta deve essere nella stessa
    > directory dell'eseguibile o la directory
    > corrente, in cui il "contagiatore" ha avuto modo
    > di scrivere dato che gli altri percorsi di
    > ricerca sono o dovrebbero essere protetti. Il
    > programma deve poi essere eseguito con privilegi
    > elevati dal sistema o
    > dall'utente.
    Quindi un exe eseguito con privilegi piu alti che ricerca le librerie
    anche nella directory corrente dell' utente a bassi privilegi allora potrebbe essere un baco.
    Questo perchè potrebbe caricare una libreria non genuina.

    A questo URL ho trovato l' algoritmo di ricerca delle librerie:

    http://msdn.microsoft.com/en-us/library/ms682586%2...
    non+autenticato
  • E' inutile che sbraitate contro Windows, perchè anche voi linari e macachi avete lo stesso bug. Qualunque OS con librerie a caricamento dinamico presente sul mercato è affetto dal medesimo bug.
    L'unica azienda che ha già rilasciato una patch è Microsoft:
    http://support.microsoft.com/kb/2264107/en-us
    non+autenticato
  • Quello credo sia appunto il workaround di cui parlava l'articolo.

    In *nix le librerie sono sempre negli stessi posti, ma possono essere usate o modificate le variabili di ambiente per farle caricare in altre posizioni.
    In linux il caricamento di una libreria da percorsi alternativi credo sia un'eccezione non la regola.
    Ma forse Microsoft si riferisce ad altri meccanismi che io non conosco(molto probabile), non si smette mai di imparare.
    Inoltre credo che anche il funzionamento ed il caricamento dei programmi sia leggermente diverso per quel che riguarda le *librerie. Magari c'è qualcuno con maggiori conoscenze che mi può illuminare.
    non+autenticato
  • - Scritto da: suc
    > E' inutile che sbraitate contro Windows, perchè
    > anche voi linari e macachi avete lo stesso bug.
    > Qualunque OS con librerie a caricamento dinamico
    > presente sul mercato è affetto dal medesimo
    > bug.
    > L'unica azienda che ha già rilasciato una patch è
    > Microsoft:
    > http://support.microsoft.com/kb/2264107/en-us

    Io sapevo che senza i permessi di root l'elenco delle directory delle librerie condivise non le cambi...
    Shiba
    4063
  • - Scritto da: Shiba
    > Io sapevo che senza i permessi di root l'elenco
    > delle directory delle librerie condivise non le
    > cambi...

    idem sotto Windows
    non+autenticato
  • - Scritto da: suc
    > - Scritto da: Shiba
    > > Io sapevo che senza i permessi di root l'elenco
    > > delle directory delle librerie condivise non le
    > > cambi...
    >
    > idem sotto Windows


    Già... ma voi siete tutti admin no? Sicuro... e anche senza password, si xche Bill vi ha insegnato questo...
    non+autenticato
  • Anche la mia alfa da 150cv mi porta a correre a 220, basta pigiare l'acceleratore.

    Però non lo faccio. Chissà perchè....

    Se ti è permesso di default fare una cosa non vuol dire che sia giusto farla (leggi o meno). Anche fumare mi è permesso, però non lo faccio, forse perchè non sono scemo?

    Ma si sa...i linari usano solo e sempre linux. Anche quando hanno incominciato. A no! Hanno usato Windows! Chissà perchè!
    non+autenticato
  • - Scritto da: ture muture
    > Anche la mia alfa da 150cv mi porta a correre a
    > 220, basta pigiare
    > l'acceleratore.
    >
    > Però non lo faccio. Chissà perchè....

    Perché per poter guidare c'è la scuola guida. Per usare un computer no.
    Shiba
    4063
  • - Scritto da: Shiba
    > Io sapevo che senza i permessi di root l'elenco
    > delle directory delle librerie condivise non le
    > cambi...

    per modificare la LD_LIBRARY_PATH non occorre essere root....
    non+autenticato
  • Scusate l'OT
    Ho bisogno di entrare nella cartella System Volume in XP Home ma non riesco nemmeno da riga di comando come istruzioni da sito M$.
    Qualcuno sa darmi una dritta per sbloccare il tutto?
    Ringrazio infinitamente tutti! Sorride
    non+autenticato
  • - Scritto da: Chiedo aiutino
    > Scusate l'OT
    > Ho bisogno di entrare nella cartella System
    > Volume in XP Home ma non riesco nemmeno da riga
    > di comando come istruzioni da sito
    > M$.
    > Qualcuno sa darmi una dritta per sbloccare il
    > tutto?
    > Ringrazio infinitamente tutti! Sorride

    Scarica una immagine di linux, ti fai una chiavetta bootabile, rebooti da chiavetta e poi accedi tranquillamente a quella directory.
  • Imposta i permessi sulla cartella, di default non ce li hai
    non+autenticato
  • Perchè devono creare cose che non stanne in cielo e neanche in terra.

    Come dicono i linari, mettere i permessi delle cartelle dove ci sono i binari in sola lettura?

    Arriva il virus e li si inchioda. Chiamo l'amministratore di sistema e quello quando vede cosa voglio installare cancella il programma e torna a ronfare.
    ( se non sbaglio chmod docet )

    Certo che se do permessi di amministratore a tutti i programmi, allora su tutti i sistemi ci sono vulnerabilità ( gli spalanchi la porta ).
  • Se è per questo, il sistema multi utenza di windows non è ancora fatto "bene" su quei versanti..... non ti obbliga nemmeno a fare la password!
    Sgabbio
    26177
  • ma se uno non è capace di farsi un account standard son fatti suoi... non dico di configurare come si deve applocker ma almeno evitare du usare un account admin e disabilitare uac...
    non+autenticato
  • il problema è che ci sono programmi del cacchio che non funzionano senza utente admin... tu dirai che sono programmi da evitare... ma molto spesso sono software di controllo di macchine che non hanno alternativa... ovvio che queste non hanno accesso ad internet... ma alla lan per forza...

    Il cancro sono i programmatori idioti e un SO debole...
    non+autenticato
  • windows ormai è parecchio robusto, le guidelines ci sono eccome a differenza di quello che diceva qualcuno più in alto... sono d'accordo con chi dice che microsoft è troppo permissiva, quello sì... dovrebbe segare la compatibilità a tutti i programmi scritti male... ma poi sarebbero tutti li a dire che fa skifo perchè non è retrocompatibile...
    non+autenticato
  • il problema è che sono linea guida, ma a livello tecnico è solo roba "da consiglio" purtroppo.
    Sgabbio
    26177
  • > Il cancro sono i programmatori idioti e un SO
    > debole...


    Già, tutta gente che viene su a suon di wizard, di.net o visual studio...
    Insomma... i NON programmatori, quelli che sanno prendere x i fondelli moltissima gente winara come loro..
    non+autenticato
  • - Scritto da: RealENNECI
    >
    >
    > Già, tutta gente che viene su a suon di wizard,
    > di.net o visual
    > studio...
    > Insomma... i NON programmatori, quelli che sanno
    > prendere x i fondelli moltissima gente winara
    > come
    > loro..

    Ahaha ha parlato lo "sviluppatore" in PHP.
    PHP!!!!! Ahahahhaha!!!!|
    Basta ti prego, mi fai morire così!!!!

    Rotola dal ridere
    non+autenticato
  • - Scritto da: Uno
    > - Scritto da: RealENNECI
    > >
    > >
    > > Già, tutta gente che viene su a suon di wizard,
    > > di.net o visual
    > > studio...
    > > Insomma... i NON programmatori, quelli che sanno
    > > prendere x i fondelli moltissima gente winara
    > > come
    > > loro..
    >
    > Ahaha ha parlato lo "sviluppatore" in PHP.
    > PHP!!!!! Ahahahhaha!!!!|
    > Basta ti prego, mi fai morire così!!!!
    >
    > Rotola dal ridere


    Ridi ridi, io solitamente rido quando le vostre applicazioni enterprise si sfasciano da sole.. ma non più di tanto, visto che ormai è all'ordine del giorno...

    ASP? ahahahahha dio che ridere...
    non+autenticato
  • - Scritto da: abcb
    > il problema è che ci sono programmi del cacchio
    > che non funzionano senza utente admin... tu dirai
    > che sono programmi da evitare...


    bene, quei programmi li fai andare con diritti di amministratore, gli altri no.
  • "Disponibile un primo walkaround, che però non risolve il problema".

    Ma che significa? Abbiamo appurato che il problema c'è ma
    non lo sappiamo risolvere, nel frattempo pasticciate un po'
    con queste istruzioni per divagarvi?

    Perplesso
  • Ok, una volta individuato il problema, lo si deve risolvere. PUNTO. Una ditta seria farebbe così: con la prossima patch l'API LoadLibrary[Ex] accetta solo percorsi completi, se si specifica qualcosa del tipo LoadLibrary("user32.dll") ritorna un puntatore NULL come se non la trovasse.

    I programmi che non rispettano questa regola smettono di funzionare e le SWhouse rilasceranno le loro patch.

    Il problema di Window$ che è instabile, bacato e accrocchiato è anche dovuto a questo: M$ negli anni non ha mai saputo mettere dei paletti, che andassero oltre alle semplici "guide-lines" (che i programmatori della domenica non rispettano e molto spesso neppure le SWhouse, tanto "funziona lo stesso").

    Non esiste neanche un meccanismo di aggiornamento simultaneo di tutte le applicazioni, di localizzazione delle applicazioni in base alla lingua dell'utente, i settaggi vengono salvati un pò nel profilo, un pò nel R€gi$tr¥, un pò chissà dove... Questo perchè? Perchè ogni applicazione è fatta secondo l'estro del programmatore e non segue le direttive (inesistenti!!) dell'OS ospitante.
    non+autenticato
  • Finalmente qualcuno che ha capito il vero problema!
    Sono anni che girano programmi che non sanno nemmeno prendere delle variabili!!
    Così un programma inglese può fallire l'installazione perchè non trova la cartella "Program Files" o può crearla a proprio piacimento!!

    Ma santo dio...
    non+autenticato
  • - Scritto da: Andrea Cerrito
    [CUT]
    > Così un programma inglese può fallire
    > l'installazione perchè non trova la cartella
    > "Program Files" o può crearla a proprio
    > piacimento!!

    ovviamente le versioni di questi programmi per Linux
    funzionano AD AETERNUM
  • - Scritto da: sentinel
    > ovviamente le versioni di questi programmi per
    > Linux
    > funzionano AD AETERNUM
    Il sw per Linux non è perfetto (nulla lo è), ma è molto più "omogeneo" dei vari sw per Winzozz. E questo principalmente per 3 motivi:

    1) Su Linux (e OSX) ci sono dei paletti e delle convenzioni che devono essere rispettate, su M$ ogni programmatore fa come cavolo preferisce, tanto "funziona lo stesso"

    2) Molti dei programmi per Linux sono scritti da appassionati, che quindi cercano di fare le cose il meglio possibile

    3) Il vantaggio dell'opensource è che se devo fare un nuovo programma posso prendere spunto da quelli esistenti, riciclando parti di codice
    non+autenticato
  • Quindi, riguardo la programmazione, Windows è Open e Linux è Closed Con la lingua fuori
    non+autenticato
  • - Scritto da: Uno a caso
    > Quindi, riguardo la programmazione, Windows è
    > Open e Linux è Closed
    > Con la lingua fuori

    A bocca aperta
    non+autenticato
  • - Scritto da: Uno a caso
    > Quindi, riguardo la programmazione, Windows è
    > Open e Linux è Closed
    > Con la lingua fuori

    Riguardo l'orifizio anale, windows e' open e linux e' closed!
  • Infatti le "Windows Best Practices" prevedono questo:

    Clicca per vedere le dimensioni originali

    Rotola dal ridere Rotola dal ridere
    non+autenticato
  • - Scritto da: Uno a caso
    > Quindi, riguardo la programmazione, Windows è
    > Open e Linux è Closed
    > Con la lingua fuori

    tutto quello che si vuole: open, closed, bacato, brutto, pessimo, cattivo, berlusconiano, escrot, scegli quello che vuoi.

    Ma gli IDE Borland ( ora embarcadero ), tolto qualcosa di os/2 e kilix, per il resto sono solo windows (solo Windows, con la lettere maisucola ).

    Mi lascio rodervi il fegato con comodo, dite pure Micro$oft, micrtoaltro, winzoz, dopotutto dovete riprendervi dalla cocente delusione.
  • - Scritto da: Andrea Cerrito
    > Così un programma inglese può fallire
    > l'installazione perchè non trova la cartella
    > "Program Files" o può crearla a proprio
    > piacimento!!

    ciccio, guarda che non è più vero quello che tu dici da almeno il 2007, da quanto è uscito Vista, che ha introdotto i link simbolici e quindi Programmi è un puntatore simbolico a Program Files.
    non+autenticato
  • Sono finalmente riusciti a copiare il comando "ln" di *nix??!! A bocca aperta
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 7 discussioni)