Cerca nel blog

2009/11/20

Falla SMB in Windows 7, quanto è grave?

Windows 7 paralizzabile da remoto? Facciamo il punto


L'articolo è stato aggiornato dopo la pubblicazione iniziale.

Windows 7, il nuovo gioiello di Microsoft, debutta col buco. E che buco, stando al suo scopritore Laurent Gaffié: è possibile paralizzare Windows 7 (e anche alcune versioni di Windows Server 2008) semplicemente inducendo l'utente a cliccare su un link appositamente confezionato, per esempio per visitare un sito Web ostile. Niente schermo blu classico, ma un blocco completo: il computer cessa di rispondere ai comandi. È quindi necessario riavviarlo, con conseguente perdita dei dati non salvati. Imbarazzante.

Microsoft sta già lavorando all'aggiornamento per turare la falla, ma nel frattempo le dimostrazioni dell'estrema facilità con la quale si può sfruttare il difetto cominciano a circolare in Rete.

La prima dimostrazione, naturalmente, è quella dello scopritore, che l'11 novembre ha pubblicato poco responsabilmente tutto il codice Python da usare. Per questo ho aspettato inizialmente a diffondere la notizia (il mio primo accenno pubblico è del 17), ma ora che tutti i dettagli sono disponibili nei principali siti di riferimento per la sicurezza (nella mailing list Full Disclosure, per esempio) è inutile mantenere ulteriormente l'embargo.

Come funziona la falla? È abbastanza semplice. Il software Microsoft che in Windows 7 gestisce il protocollo SMB (Server Message Block), quello utilizzato normalmente nei computer Windows per la condivisione di file e stampanti, non gestisce adeguatamente eventuali incoerenze nei dati trasmessi nell'ambito di questa condivisione. Specificamente, Windows 7 si blocca completamente (va in loop infinito) se riceve l'header di un pacchetto di dati SMB che dichiara una lunghezza diversa da quella reale. È sufficiente un singolo byte di differenza, secondo i test di PraetorianPrefect.com. Se succede, l'unica cosa che si può fare è premere il pulsante di spegnimento del computer e poi riavviare.

Un malintenzionato non deve fare altro che predisporre un server sul quale gira il codice pubblicato da Gaffié, lasciarlo in ascolto e indurre la vittima, tramite un qualunque espediente psicologico (mail allettante, invito in chat), a visitare una pagina Web contenente un link speciale che rimanda al server ostile. Quando la vittima contatta la pagina Web, si attiva una connessione SMB che manda il pacchetto malformato a Windows 7, che si paralizza. Ci sono anche altri metodi (un comando dir \\indirizzo ip\risorsa condivisa fasulla dalla macchina della vittima), ma questo è probabilmente il più pernicioso.

Microsoft ha pubblicato un advisory in inglese, in cui raccomanda agli utenti Windows 7 di bloccare le porte TCP 139 e 445 al firewall e di bloccare ogni comunicazione SMB da e verso Internet. Di norma dovreste già essere configurati in questo modo (se avete dubbi, chiedete a un esperto fidato di controllare per voi), per cui la falla sarebbe sfruttabile solo dai vostri colleghi dispettosi. Tuttavia secondo alcune fonti esisterebbe un modo per sfruttare Internet Explorer per scavalcare anche un firewall e colpire la vittima da remoto: "includere un file presente su una condivisione nell'HTML di una pagina Web", dice Tyler Reguly di nCircle citato da PCWorld.com.

L'advisory di Microsoft indica che Windows XP e Windows Vista non sono affetti da questa vulnerabilità e sottolinea che per ora non sono noti siti che la sfruttano e non è possibile sfruttarla per eseguire codice o prendere diversamente il controllo del computer della vittima: il peggio che vi può capitare, insomma, è trovarvi con il computer improvvisamente bloccato. Proprio come ai vecchi tempi.

Fonti aggiuntive: CVE; ZDNet, The Inquirer, Slashdot, The Register.

36 commenti:

Vittorio ha detto...

...il peggio che vi può capitare, insomma, è trovarvi con il computer improvvisamente bloccato. Proprio come ai vecchi tempi.

Da vecchio utonto Microsoft, in sostanza, non è cambiato nulla (LOL)! Mi sto sempre più convincendo al passaggio su altre piattaforme, anche se purtroppo alcuni applicativi che uso frequentemente non funzionano se non sotto Windows.

Mu ha detto...

Beh, il fatto che windows si blocchi la chiamerei un passo avanti, non una falla per giunta grave.

Vittorio ha detto...

P.S. ennesima foto di gatto stupenda! Rende l'idea!
Scared!

Explobot ha detto...

Ciao Paolo, cosa intendi con "per cui la falla sarebbe sfruttabile solo dai vostri colleghi dispettosi." ? Per "colleghi dispettosi" persone che hanno accesso al nostro computer con credenziali di amministratore o semplicemente persone connesse alla nostra stessa LAN?

E' disponibile un server SMB dove è possibile verificare il problema?

Explobot ha detto...

Se ho capitole spiegazioni tecniche del sito Microsoft riguardo il problema penso che la frase "semplicemente inducendo l'utente a visitare un sito Web appositamente confezionato." sarebbe più corretto sostituirla con "semplicemente inducendo l'utente a utilizzare una URI appositamente confezionata.".

Pippolillo ha detto...

Questa è una cosa dell'informatica che non capirò mai.
In qualsiasi altro settore un nuovo prodotto è migliore e con tutte le migliorie di quelli precedenti.
Come mai Win 7 ha un baco che non hanno Win XP e Win Vista?
Ma con Win 7 hanno riscritto tutto il codice ripartendo da zero e dimenticandone un pezzo?

Forse è per questo che preferisco l'hardware al software.

Paolo Attivissimo ha detto...

persone connesse alla nostra stessa LAN?

Sì.


E' disponibile un server SMB dove è possibile verificare il problema?

Non mi risulta. L'ho proposto informalmente ad alcuni colleghi, ma il rischio che venga sfruttato per causare danni è troppo alto.


sarebbe più corretto sostituirla con "semplicemente inducendo l'utente a utilizzare una URI appositamente confezionata."

Esatto, ma il mio era solo un esempio divulgativo. E' una delle cose che si possono fare con questa vulnerabilità.

Poorman ha detto...

Lo dico sempre che Windows XP è molto meglio...

Anonimo ha detto...

"Per questo ho aspettato inizialmente a diffondere la notizia"

umm scusa ma dubito fortemente che creatori di malware e virus si informino tramite il tuo sito :)

Paolonik ha detto...

Fin qui nulla di strano, infatto volevo commentare la foto del gatto, non la falla di Seven. Splendidissimo il gatto, davvero davvero splendido :)

Camicius ha detto...

@Pippolillo
Il vero problema dell'informatica, è che non si può effettuare un vero collaudo.
Quando collaudi un ponte, lo carichi con il carico massimo ammesso, e se non cade, sei (ragionevolmente) sicuro che da zero al peso che hai caricato, il ponte sia sicuro.
Con un programma informatico, dovresti provare tutti i pesi da zero al carico massimo, magari in step di 1kg. E se non cade poi, comunque potrebbe caricarsi con un mezzo chilo e cadere.
è un dramma che è intrinseco nella natura dell'informatica...

Spazio1999 ha detto...

"La prima dimostrazione, naturalmente, è quella dello scopritore, che l'11 novembre ha pubblicato poco responsabilmente tutto il codice Python da usare."

Monty Python? :-)

Tukler ha detto...

@Pippolillo:
Solitamente un nuovo prodotto è migliore del precedente, ma per renderlo migliore vuol dire che hanno aggiunto nuove funzionalità, nuovi controlli o ne hanno ridisegnato alcune parti.
E tutte queste novità ovviamente sono soggette a imperfezioni (bug) tanto nell'hardware quanto nel software.

Per continuare l'esempio di Camicius, è come se io decido di demolire un orrendo ponte a pilastri di cemento e costruire un bellissimo ponte metallico a sospensione progettato per sostenere qualsiasi peso... poi arrivano i soldati in marcia a cui non avevo pensato, mi fanno partire la risonanza e crolla tutto:P

Giovanni ha detto...

Qui però il buco è una scarsa implementazione di protocollo.
Se ti dicono "seguono n bytes" poi sta a te, che ricevi, verificare come gestire se ne ricevi m<>n.
Non farlo accelera lo sviluppo ma rende il prodotto una chiavica.
E, se prima il buco non c'era hanno fatto qualche casino:
E' come se, nel rifare il ponte avessero demoito anche parte della strada d'accesso e poi avessero lasciato quei pezzi in terra battuta :-)

Giovanni

Per Vittorio: verifica se giano con Wine - io ho risolto così un paio di casi:
pc -> linux (p.es. ubuntu) -> Wine -> applicativo sviluppato per win

lucac81 ha detto...

Da notare che questo problema è parecchio simile al vecchio win nuke presente sui sistemi 95/98 e persino XP...
Segno che forse tante novità nel codice di windows non ci sono... o forse sono affezionati ai vecchi bug ;-)

Vittorio ha detto...

@ Giovanni
Grazie, è che la maggior parte sono dei giochi-simulatori: Train Simulator, per capirsi e programmini di contorno quali modellatori 3D...
Dubito fortemente girino sotto Wine.

Tukler ha detto...

@Giovanni:
Si, più che altro a quanto ho capito il problema è che se mandi meno byte di quelli che dichiari il sistema rimane bloccato in attesa.

D'altronde SMB ha sempre avuto grossi problemi di timeout, non so se vi è mai capitato di provare ad accedere a condivisioni non più attive e vedere explorer bloccato per qualche secolo prima del messaggio d'errore.

Magari cercando di risolvere quello avranno messo da qualche parte una read bloccante dimenticandosi di darle un timeout:P

Tukler ha detto...

@Vittorio:
Train Simulator dovrebbe girare.

Per vedere quali applicazioni sono state testate con successo su Wine e quali no, trovi molti risultati (ed eventualmente spiegazioni) su http://appdb.winehq.org/

Vittorio ha detto...

Train Simulator dovrebbe girare
:-)) Finalmente una buona notizia ogni tanto!

stell ha detto...

Questo è un errore di programmazione, come ce ne possono essere altri mille. Ma specialmente, come è normale che possa accadere in un software delle dimensioni di un sistema operativo.
Non mi pare poi che crei problemi, nella peggiore delle condizioni blocca la macchina.
E per avverarsi devono accadere parecchie cose (l'esempio dei colleghi dispettosi è un po fuori dalle probabilità): porte aperte, servizio attivo, incoscienza dell'utente.
Mi sembra un po troppo rumore per nulla.

Guido ha detto...

>> Questa è una cosa
>> dell'informatica che non capirò
>> mai.
>> In qualsiasi altro settore un
>> nuovo prodotto è migliore e con >> utte le migliorie di quelli
>> precedenti.

Micca vero.

Cosi' su due piedi mi vengono in mente...

Per esemp io la qualita' del modello Nissan Micra e' decisamente peggiorata negli anni.

La qualita' dei gelati della IceMan (vendita porta a porta) per quel che mi riguarda e' calata.

ecc...

E poi non c'e' un cazzo da fare... l'entropia nell'universo aumenta... il software non fa eccezione.

Passato un numero sufficente di anni un qualsiasi prodotto software diventa ingestibile e bisogna buttare tutto nel cesso e riscrivere da zero.

La differenza tra un software ben fatto e uno mal fatto sta solo nel come e nel quanto tempo si arriva al capolinea.

Jena Plisskin ha detto...

@Spazio 1999: se ricordo bene, l'autore di Python lo ha chiamato così proprio per omaggiare i Monthy Python.

Explobot ha detto...

@ Guido

> E poi non c'e' un cazzo da fare...
> l'entropia nell'universo aumenta...
> il software non fa eccezione.

Sante parole, e poi ricordiamoci che "è il caos che ha ucciso i dinosauri".

dovella ha detto...

Windows 7 has no back door
http://bit.ly/UEJC5

spero di esservi stato utile

david ha detto...

"Mi sembra un po troppo rumore per nulla."

Straquoto.
Come sempre fanno a gara per trovare falle su Windows, che noia....

FenderJazz ha detto...

Funziona funziona, testato di persona su macchina virtuale!

Tukler ha detto...

@Paolo Attivissimo:
C'è una piccola imprecisione nell'articolo.

Chiudendo le porte 139 e 445 sul firewall della tua LAN (che ovviamente sono sempre chiuse o ben configurate nei router privati e nel 99% dei firewall aziendali), eviti attacchi indiscriminati dall'esterno che sarebbero molto fastidiosi (tipo i messaggi netbios che arrivavano un tempo quando si usava la 56k).

Ma rimani comunque vulnerabile agli attacchi confezionati in pagine web, che forzano il tuo sistema a connettersi ad un server remoto che scatena il bug.

E' spiegato un po' meglio qui.

L'unica soluzione è chiudere tramite Windows Firewall le porte 139 e 445 sia in entrata che in uscita, oppure disattivare direttamente il servizio condivisione.

In entrambi i casi ovviamente si perde la possibilità di condividere file.

Tra l'altro non sono riuscito a capire se il servizio è attivato di default in Windows 7, anche se suppongo di si. Qualcuno ne sa qualcosa? FenderJazz?

PUOjACKz ha detto...

Caso di Resource Exhaustion. Non vi è un BSoD invocato dal sistema, in quanto, il problema non va ad incidere nei moduli del kernel o nei device driver. Tutto si svolge a liv. User. Qualcuno dice: Ma scusa, ma se fosse come dici tu, il sistema dovrebbe bloccargli il Loop. Sì... se tale protezione è implementata (es. vedi Firefox e IE con certi script). Qua, però, il problema è un altro. A parte le trollate da fanatici Windows-Linux, che non c'entrano in questo caso, il principio è questo: il bug identificato è vergognoso. Capisco Win9x. Lì il problema era dovuto da una concomitanza di fattori. Ma non s'è manifestato niente del genere nè su XP, nè su Vista. Come mai su Seven sì? Ed il resto del codice presente nell'OS? Se è affetto da bug "stupidi" (e con questo termine non voglio scatenare flame) di questo liv., figurati la sicurezza. Hai voglia tu a piazzarci UAC, Firewall ecc.

Tukler ha detto...

@PUOjACKz:
Oltre alle sviste nella scrittura del codice, che ci possono sempre scappare, la cosa per me più preoccupante è la mancanza di test...

Visto che SMB è sempre stato uno dei servizi più pieni di falle, si presume che un po' di unit testing sui pacchetti malformati varrebbe la pena di farlo, no?

Ma se l'avessero fatto la lunghezza non sarebbe stata la prima cosa che avrebbe testato?

Capisco se fosse stato qualche caso particolarissimo di buffer overflow in qualche campo esoterico che non si usa mai... ma cavolo, la lunghezza...

Explobot ha detto...

@Paolo Attivissimo e @Tukler

Sto leggendo tutte le spiegazioni sia dell'articolo che dei commenti cercando di capire esattamente il meccanismo che porta al crash. Tutte le fonti concordano nell'individuare il problema in un baco dell'SBM nell'interpretare messaggio malformati riguardo la lunghezza dei messaggi. Mi pare anche evidente che il crash si manifesti lato client (lo afferma per esempio l'articolo lincato da Tukler: "Exploitation of this vulnerability occurs when a user attempts to browse to Windows Share hosted on the malicious server"). Però in più parti si consiglia di chiudere le porte 139 e 445 sia in uscita che in entrata (non basterebbe solo in uscita?) oltre che bloccare il servizio condivisione, che - però potrei essere smentito in quanto non mi occupo più seriamente di reti in ambito Windows dai tempi di NT - penso che non risolva il problema in quanto non impedisce al sistema operativo di accedere al servizio SMB su altri server.

@Paolo

Riguardo la possibilità di sfruttare la falla dall'interno della LAN anche se le porte in questione sono chiuse nel firewall locale ho qualche perplessità; sinceramente non capisco alla luce delle mie conoscenze (felice di essere smentito e quindi di imparare qualcosa di nuovo) come sia possibile, se io ho chiuso sia in ingresso che in uscita le porte 139 e 445 nel firewall locale, che il computer acceda a un serivizio SMB anche se all'interno della LAN.

Sempre riguardo alle mie osservazioni riguardo la frase "semplicemente inducendo l'utente a visitare un sito Web appositamente confezionato." concordo sulla necessità di semplificare i testi a scopo didattico, ma penso che parlare di "sito web" in questo caso sia un errore, non una semplificazione, secondo me sarebbe stato meglio scrivere "semplicemente inducendo l'utente a cliccare su un link appositamente confezionato.". (ripeto: IMHO)

@FenderJazz

Potresti fornire qualche maggiore informazione riguardo il tuo test su una macchina virtuale, sono curioso e vorrei ripetere l'esperienza, fremo dalla voglia di verificare la cosa e vedere la mia macchina inchiodarsi!

Explobot ha detto...

Riguardo la possibilità di sfruttare la falla dall'interno della LAN anche se le porte in questione sono chiuse nel firewall locale ho qualche perplessità;

Ho caito, l'advisory di Microsoft parla genericametne fi firewall e di conessioni con Internet, io avevo interpretato come firewall locale. Sorry!

Tukler ha detto...

@Explobot:
Mi pare anche evidente che il crash si manifesti lato client. Però in più parti si consiglia di chiudere le porte 139 e 445 sia in uscita che in entrata (non basterebbe solo in uscita?)

Si in effetti in tutti gli esempi l'attacco avviene facendo connettere il client a server confezionati, quindi molto probabilmente è solo lato client.

Però si parla molto esplicitamente di chiudere le porte in entrata, non può essere solo una questione di interpretazione.

L'advisory Microsoft dice "protect networks from attacks that originate outside the enterprise perimeter.[...] the SMB ports should be blocked from the Internet." e l'articolo che ho linkato "Blocking TCP ports 135 through 139, and port 445 will prevent outside SMB traffic from entering the network.".

Quindi a sto punto penserei che esiste il modo per un server SMB di forzare una connessione di un client tramite SMB stesso.

Ora, SMB l'ho guardato un po' tanto tempo fa, ma mi pare che esista una specie di comando ANNOUNCE che consente al server di elencare al client le risorse che mette a disposizione, forzandolo quindi ad andare a indicizzarsele.

bloccare il servizio condivisione, che penso che non risolva il problema in quanto non impedisce al sistema operativo di accedere al servizio SMB su altri server.

Hai ragionissima! M'ero fatto distrarre da chi parlava di attivare il servizio...
Si è vero, il fatto che sia attivato o meno SMB server non conta niente, tanto SMB client è sempre attivato di default!

Paolo Attivissimo ha detto...

Grazie Tukler,

ho aggiunto la tua segnalazione.

Anonimo ha detto...

smb che è il servizio di condivisione di file e stampanti, che guarda caso è MOOOOOLTO simile a samba... :D un caso? Loro di Boyager credono di no ;)

comunque basta segare il relativo servizio e stai tranquillo... Poi verrà fuori un'altra vulnerabilità su un altro servizio e seghi anche quello... alla fine hai segato tutto e forse ti sei reso conto che Windows non è poi così sicuro e passi a Linux ;) (si scherza eh!!!)

seriamente, non so quanta gente usi in casa la condivisione file e stampanti... e se sei in un ufficio comprati un print server (pezzente)!!! o una stampante predisposta per lavorare in rete... ;)

povero windows... tutti a parlarne male... :)

ma perchè si può anche parlane bene?
:)))))))))))))))))))))))))

(so già che scatenerò una religion war con 'sto discorso...)

Anonimo ha detto...

Ben fatto. Davvero "sfizioso" il Blog e principalmente per la notizia che mi ha portato qui, quella inerente a "Seven" ed il suo ipotetico (non più di tanto però) BUCO. Approfitto dell'occasione per esternarti tutta la mia simpatia e ho già provveduto a commentare la tua notizia con il relativo link sul mio blog. Spero di fare cosa gradita. Ciao e grazie.
Raffaele Vertaglia.

Tukler ha detto...

@Guido:
Che SMB sia molto simile a Samba non è per niente casuale, dal momento che Samba è un sistema creato per offrire a Linux ed altri sistemi la compatibilità con SMB, attraverso reverse engineering di quest'ultimo...

Occhio che comunque la "condivisione file e stampanti" non c'entra niente, perché la vulnerabilità è nel client, non nel server.
Non devi attivare niente, il sistema è già vulnerabile di default.
Disattivare il client non è esattamente la cosa più intuitiva da fare su Windows XP, e non credo neanche lo sia su Seven.