skip to main | skip to sidebar
113 commenti

Falla nel TCP/IP di Windows permette di infettare i PC

L'articolo è stato aggiornato dopo la pubblicazione iniziale.

Il bollettino di sicurezza MS11-083 di Microsoft (Vulnerability in TCP/IP Could Allow Remote Code Execution) definisce “critica“ la falla nel TCP/IP di Windows Vista, Windows Server 2008 e Windows 7 che “potrebbe consentire l'esecuzione di codice da remoto se un aggressore invia un flusso continuo di pacchetti UDP appositamente confezionati a una porta chiusa del sistema-bersaglio... un aggressore potrebbe eseguire codice arbitrario in kernel mode” e “potrebbe poi installare programmi; visualizzare, modificare o cancellare dati; oppure creare nuovi account con pieni permessi d'utente”. Ironicamente, Windows XP è immune al problema. Idem dicasi per Windows Server 2003.

Secondo Kevin Mitnick via Twitter, questo potrebbe essere un video che dimostra la falla e il suo utilizzo (su una rete locale):


È una falla decisamente bizzarra, perché è così facile da sfruttare e perché è sorprendente che esista: mandi via Internet i pacchetti UDP malformati e prendi il controllo della macchina-bersaglio. Tutto qui. Oltretutto attraverso una porta chiusa, che come tale dovrebbe dare una certa protezione. Anche per F-Secure la falla è piuttosto soprendente; Technet di Microsoft fornisce dettagli e smorza la sfruttabilità del difetto. L'aggiornamento è in arrivo già disponibile fra quelli mensili del Patch Tuesday dell'altroieri; se usate i sistemi operativi affetti, aggiornateli appena possibile.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (113)
Ma quanta gente vive e lavora grazie ai colossali bug windows?
Pesante... fortunatamente il mio amato win7 lavora dietro un firewall linux :D
Credo che sia MS11-083, non MD11-083
Grossomodo quanta ne vive e lavora risolvendo i colossali bug degli altri OS. Ah no scusa molti tecnici che lavorano su Linux lo fanno gratis.
Beh però per far arrivare i pacchetti sul pc / server in questione vuol dire che il firewall / router è configurato per far passare tutto il traffico in ingresso in nat su quel pc / server, che senso ha? Generalmente si aprono da firewall/router solo le porte utilizzate, quindi perché dovrebbero arrivare pacchetti su porte non utilizzate fino al pc / server? Poi che il bug sia da risolvere è sacrosanto, ma se venisse un po' più apprezzato il nostro lavoro di Sys Admin sarebbe anche meglio....
Wow mi ricorda il vecchio ping of death. di semplice esecuzione e sicuro effetto... a Redmond si che sanno come confezionare bug :D
Ma... Kevin Mitnick non aveva avuto l'interdizione perpetua all'uso di apparecchiature informatiche?
http://technet.microsoft.com/en-us/security/bulletin/ms11-083
Mario: più o meno quanta ne vive e lavora grazie ai colossali bug degli altri sistemi operativi. Con la differenza che su alcuni OS, tipo Linux spesso lavorano gratis.

Paolo: mi piacerebbe vedere quello scriptino in python, provo a fare un reply a Mitnick :p
Scusate il doppio post, a quanto sembra il video è un fake. Almeno, stando ad uno dei commenti allo stesso:

Pretty sure this is bullshit. What's publicly known about the vulnerability is that it takes 2^32 (4294967296) packets to trigger the vulnerability, meaning that if you can send 1000 packets per second, it'll take approximately 49 days to send enough packets, and you need to know when exactly enough packets have been sent in order to exploit it. That said, LOL
Ieri sera ho lasciato il mio PC (su cui gira Vista) loccato come sempre. E questa mattina l'ho trovato al "login". Ora ho capito perchè. Security update in emergenza... Congrats Microzoz :D

E grazie, Paolo.
oppure semplicemente NON usate windows ;)
[quote-"Mario"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c6747095140756340599"]
Ma quanta gente vive e lavora grazie ai colossali bug windows?
[/quote]

Per come la vedo io, meno di quanta ne vivrebbe se le cose funzionassero bene. Invece di perdere tempo a rabberciare sistemi e a "vivicchiare" si potrebbe usare il tempo per aumentare le efficienze e gli sviluppi.
Se il mio macellaio vendesse le salsicce con la qualità di alcuni prodotti informatici avrebbe chiuso dopo una settimana.
Immagino la scena, la signora che torna con una bisteccona abitata da una piccola colonia di vermicelli e il macellaio la guarda e con aria sorniona le si rivolge << Signora mi spiace, la bistecca è venduta as is, quello è solo un bug, se torna il secondo martedì del mese e do una patch per pulire la sua bisteccha >>
Credo ci sia un typo, il bollettino è MS11-083 ( http://technet.microsoft.com/it-it/security/bulletin/ms11-083 )
La CVE-2011-2013 è la prima 'three times ten' nella storia di CVSS.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2013

Un giorno memorabile per tutti i professionisti di Vulnerabilty Management.
Incredibile, per fortuna il mio server casalingo sta dietro un firewall che accetta connessioni soltanto da specifici indirizzi IP ;)
Falla a dir poco clamorosa, ma per dovere di precisione la patch è già uscita da due giorni:
https://technet.microsoft.com/en-us/security/bulletin/ms11-083
CVE-2011-2013 è l prima 'three times ten' della storia di CVSS.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2013

Un giorno memorabile per tutti i professionisti di Vulnerabilty Management.
Minghia!!! :-O
Addirittura diventi l'utente di systema!
Meglio che amministratore!
Ma nemmeno su un blog serio come questo si riescono ad evitare i commenti da bambini dell'asilo come quello di Mario? A parte ciò, il codice corretto è MS11-083, per chi ha necessità di approfondire...
Annamo bene... O_O
Ovviamente se siete dietro un firewall il problema non sussiste (a meno che l'attacco non provenga da vostra moglie o dal vostro collega di lavoro...) fermo restando che la patch va applicata...
Non vorrei dire un cavolata, ma mi sembra che TCP e UDP siano due protocolli paralleli ma separati, nel senso che entrambi fanno parte del livello di trasporto OSI, ma sono due cose diverse che non dipendono l'una dall'altra.
Penso sia errato quindi dire che la falla è sul TCP/IP se i pacchetti vanno mandati tramite UDP.
Naturalmente potrei sbagliarmi, ma magari un controlo o un chiarimento non dispiacerebbe.
Da quello che so molti personal firewall per windows permettono di bloccare completamente pacchetti udp (e non solo) malformati. Comunque sarebbe bello provare sulla propria macchina questo tipo di attacco, peccato che i soliti lamer di turno lo userebbero per attaccare i computer di altre persone.
Possibile refuso: è così facile da sfruttare CHE è sorprendente che esista
C'è un minuscolo refuso all'inizio del post, il nome corretto del bollettino è MS11-083 ;)
Come sempre articolo interessante :-)

Il problema, dal tuo articolo, sembra riguardare solo eventuali attacchi in rete locale.

Se il PC si trova dietro un router in effetti dovrebbe essere più difficile riuscire ad attaccarlo (ovviamente se l'attaccante NON si trova nella stessa rete locale), specie se il router ha anche un firewall base con le porte chiuse.

Però oggi molti si connettono con una InternetKey e, se non sbaglio, con quella viene creata una connessione diretta ad internet.
E' ora di finirla di fare terrorismo informatico, perfino nei bugiardini dei medicinali ce l'hanno fatta a dare un'indicazione della effettiva consistenza dei rischi di certi effetti collaterali.
Certo, in potenza si possono fare un sacco di cose, peccato che in pratica sarà un altro di quei bug che suscitano qualche clamore mediatico ma che all'atto pratico finiranno nel dimenticatoio senza passare dal "via".

E' paradossale che da una parte tieni un (buon) servizio antibufala, che vuole sbufalare falsità e montature dando un quadro completo al lettore, mentre dall'altra presenti un bug parlando solo di ciò che in potenza potrebbe accadere ma senza dare alcuna informazione di quello che verosimilmente accadrà.

Lo dico io, avendo letto due cose a riguardo: un cazzo. Ci scommettiamo? Se ho ragione io accogli il mio suggerimento e dai un'indicazione ragionata (e poi verificata) del rischio per l'utente comune, quando parli di falle di sicurezza. Il che sarebbe un servizio non da poco, al pari del servizio antibufala.
Si tratta della falla MS11-083, MD11-083 non esiste.

https://technet.microsoft.com/en-us/security/bulletin/ms11-083
scusa paolo è MS11-083, Windows Update mi ha appena proposto l'aggiornamento.
Stamattina Microsoft ha rilasciato 4 aggiornamenti di protezione per Win 7 a 64 bit: KB2620704, KB2588516, KB2617657, KB89083, e a giudicare dalle note, sembrerebbero riguardare questo problema:

[...] È stato individuato un problema di protezione che potrebbe consentire a un utente remoto non autenticato che effettua un attacco di danneggiare il sistema e di ottenere il controllo completo su di esso. [...]
Si tratta però di una vulnerabilità che tocca chi ha una macchina direttamente esposta su Internet, senza nessun firewall, e soprattutto in ambito aziendale chi non ce l'ha .... beh ... un po' se la cerca.
Forse non avete realizzato bene la gravità di questo bug. Il sistema sta ad ascoltare su una porta TCP/IP CHIUSA! Quei pacchetti UDP dovrebbero essere semplicemente scartati.
Uno spam che mi è arrivato attraverso twitter
parte come teoria del complotto e finiscono per venderti la fontana di Trevi
http://mobilemoneymachines.com/sp/indexmmm2.html?hop=zhuwingwd
Scusate ho dimenticato di accorciare il link http://bit.ly/pSVzDx
La nota Microsoft che descrive i problemi di protezione è la stessa da quando hanno inventato Windows Update, cioè da Windows 98.
Ogni volta un malintenzionato prende possesso del computer fa quello che gli pare... questo caso è uno dei millemila patchati.
Ironicamente, Windows XP è immune al problema.
Fiuuuuu, meno male :-)
Mitnick l'aveva già tweetato (prima di beccare il video) segnalando un possibile attacco UDP. Infatti io l'avevo già letto e aspettavo Windows Update.
E i commentatori che segnalano il video come fake sono diventati ben due: in compenso la musica è assolutamente geniale e l'hanno linkata :D
@ Piergiuliano

È la classica spiegazione scritta paro paro in quasi tutti gli aggiornamenti per Windows, chissà perché :-))
@Marco: Penso sia errato quindi dire che la falla è sul TCP/IP se i pacchetti vanno mandati tramite UDP.

La tua osservazione è corretta!
In realtà il nome corretto del TCP/IP è "Internet Suite", e non è nemmeno corretto chiamarlo "protocollo" ma più precisamente si tratta di una famiglia di protocolli, della quale il TCP e l'IP sono quelli più famosi.

Poi però per convenzione il termine "protocollo TCP/IP" è entrato nell'uso comune al posto di "Internet Suite", e come giustamente fai notare questo comporta delle incongruenze: se utilizzi un servizio basato su UDP non stai usano TCP/IP, bensì UDP/IP...!

Comunque, anche se errato tecnicamente, si può tranquillamente dire che i servizi basati su UDP si poggiano sul protocollo TCP/IP....

Per quanto riguarda la falla... sì sembra incredibile, ma non c'è da stupirsi... software is hard
Non e' che l'aggiornamento sia in arrivo, e' gia' arrivato! Meglio correggere il post.
Comunque, secondo questo blog non e' poi cosi' banale l'exploit della falla, e non necessariamente da' luogo a remote code execution:
http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx
Questo commento è stato eliminato dall'autore.
@Nys Qendra: tu immagini le porte come qualcosa di fisico, del tipo porta chiusa = non passa corrente. Non funziona così. Arriva un pacchetto, lo stack tcp/ip lo "legge", vede che è destinato alla porta x, verifica che esiste una regola del firewall che prevede lo scarto del pacchetto e lo scarta (descrizione prossima alla metafora...). E' durante questo processo che, sfruttando la vulnerabilità, è possibile generare un integer overflow con le conseguenze del caso.
aggiungo un'altra cosa.... sempre prendendo come spunto il commento di prima:

@marco: mi sembra che TCP e UDP siano due protocolli paralleli ma separati, nel senso che entrambi fanno parte del livello di trasporto OSI

lo standard per le comunicazioni di rete è l'ISO/OSI, ma l'ISO/OSI e il TCP/IP (o Internet Suite, come si preferisce chiamarlo), pur presentando numerose analogie, sono due cose diverse.

In pratica per le comunicazioni di rete stiamo utilizzando uno standard che non è standard :)
@AFMcrime

Hai fatto bene a specificarlo perché sennò si fa confusione. "Porta chiusa" non si sa bene cosa significhi. Come funzioni questo sistema è abbastanza semplice: prima il sistema si preoccupa di filtrare i pacchetti verso le porte (o li fa passare o non li fa passare). Poi ad ogni porta ci può essere o no un programma in ascolto. Se il programma in ascolto non c'è non succede nulla. Se c'è allora gestisce o cerca di gestire il pacchetto.

In questo caso la falla è nel primo passo cioè nel processo di filtraggio compiuto dal software di stack: i pacchetti UDP spediti ad una porta senza alcun programma in ascolto, se sono fatti in un certo modo, non sono ben gestiti da questo software di stack. E questo può portare ad un attacco anche se non così immediato come si vuol fare credere nel video (e su questo ha ragione chi parla di fake).

Pensate che anche se si riesce a far crashare il software dello stack esso può crashare in ben 5 diversi modi di cui solo uno può essere utilizzato per eseguire del codice malevolo...
[quote-"Silvano Cavallina"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c2938920633303383952"]
... un po' se la cerca.
[/quote]

Non concordo, certo l'ignoranza non è una scusante, ma non si può pretendere che l'utente conosca le basi del firewalling.
Per usare un frigorifero mia madre non deve conoscere le basi della fisica dei gas, lo apre prende il latte e lo usa.
Per come la vedo io, l'OS deve essere diviso in due strati, il primo per l'utente che non nutre piacere per l'uso della macchina ma lo sfrutta solo come strumento, il secondo per il geek o l'appassionato in genere che riceve gusto per il solo usarlo...
In quest'ottica gli OS dovrebbero essere "blindati" e facili al primo livello ma "liberi" (Free!) ed elastici al secondo.
Ci vorrebbe una politica della software quality assurance ben stabilita che non faccia capo al principio profitto a tutti i costi.
Inoltre ci vorrebbe una trasparenza che spesso è appannaggio solo degli OSS così da permettere una rapida soluzione dei problemi, che non dimentichiamocelo, capitano SEMPRE.
Ironicamente, Windows XP è immune al problema.
Fiuuuuu, meno male :-)


Siamo in due! Fiuuuuu al quadrato ;-)
@Adriano Esposito
...E questo può portare ad un attacco anche se non così immediato come si vuol fare credere nel video (e su questo ha ragione chi parla di fake).

Sono d'accordo: l'attacco non è semplice e tantomeno immediato.
Da quello che ho capito io l'attacco funziona così.
L'attaccante invia il "pacchetto tossico" UDP al software che gestisce lo stack TCP/IP e lo manda in un "opportuno" overflow. L'overflow, infatti, deve essere "confezionato" in modo tale da far scrivere i valori giusti nei registri giusti della CPU che permettano di:

1. aprire una porta nello stack;

2. avviare il servizio telnet, di solito disattivato perché insicuro, metterlo in ascolto su quella porta e configurarlo in modo che dia l'accesso come utente system;

1. e 2. devono avvenire senza che lo stack vada in crash altrimenti il computer sotto attacco non sarà più raggiungibile da remoto.

Mica male!

O sono io che ho capito male ed è tutto molto più semplice?
Quoto Manuel #46
Manuel: se il mio business dipende da quanto rapidamente riparo i guasti in un sistema operativo, la trasparenza è l'ultima delle mie priorità.
L'Open Source in questo caso è un arma a doppio taglio: se è vero che chiunque può scovare una falla (e sono tutt'altro che rare, data la complessità dell'oggetto di cui parliamo, un sistema operativo), chi mi dice che venga corretta anche nella distribuzione che sto usando io? Non per polemizzare, lo chiedo seriamente. In questo momento sto usando una distro basata su debian e metti caso che la combinazione di programmi che stanno usando ha delle falle di sicurezza. Come so che vengono corrette? Mi devo fidare.... che strano, è la stessa cosa che si fa con gli OS closed source!
Giuseppe: a quanto so io, le vulnerabilità basate sugli overflow funzionano esattamente come hai descritto. Ma in Windows Vista e seguenti non esisteva un meccanismo per evitare che si potessero sfruttare gli overflow in questo modo?
OT: ma avete sentito l'intervento di Paolo a Caterpillar AM questa mattina, sull'11/11/11? E soprattutto, Rob "Kazzenger" Giacobbo che si dichiara daccordo con Paolo e afferma che la numerologia è una boiata? E che nel 2012 non accadrà nulla (detto dall'autore di un libro di fuffa sul 2012...LOL!)?
Quell'uomo è un gran fuffaro, ma ha classe :)
Quando sa che non può vincere, cambia strategia.
[quote-"Panzer"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c7981695759069887286"]
Ma... Kevin Mitnick non aveva avuto l'interdizione perpetua all'uso di apparecchiature informatiche?
[/quote]

Mi pare di ricordare che quando fu rilasciato fu condannato a un'interdizione dall'uso di internet, ma per soli tre anni.
@Lupo
Ma in Windows Vista e seguenti non esisteva un meccanismo per evitare che si potessero sfruttare gli overflow in questo modo?

Esistono, per quel poco che ne so, dei meccanismi per rendere più difficile sfruttare gli overflow, come Address Space Randomization (oltre al Data Execution Prevention già presente in XP), e sistemi simili sono presenti anche negli altri SO. Altre protezioni sono nei compilatori: nel caso di Microsoft, "Buffer Security Check". Ma ho sempre sentito dire che i bravi cracker sanno scavalcare anche quelle protezioni... come non lo so, non sono un cracker né buono né scarso!
tu immagini le porte come qualcosa di fisico, del tipo porta chiusa = non passa corrente. Non funziona così. Arriva un pacchetto, lo stack tcp/ip lo "legge", vede che è destinato alla porta x, verifica che esiste una regola del firewall che prevede lo scarto del pacchetto e lo scarta (descrizione prossima alla metafora...). E' durante questo processo che, sfruttando la vulnerabilità, è possibile generare un integer overflow con le conseguenze del caso.

Resta il fatto che una vulnerabilità del genere senza che vi sia nessuno in ascolto sulla porta è veramente una brutta bestia... sembra di essere tornati al leggendario TearDrop Attack (che faceva schiantare il sistema, ma non mi pare consentisse l'esecuzione di codice remoto).
[quote-"Il Lupo della Luna"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c3559068520032626384"]
Manuel: se il mio business dipende da quanto rapidamente riparo i guasti in un sistema operativo, la trasparenza è l'ultima delle mie priorità.
L'Open Source in questo caso è un arma a doppio taglio: se è vero che chiunque può scovare una falla (e sono tutt'altro che rare, data la complessità dell'oggetto di cui parliamo, un sistema operativo), chi mi dice che venga corretta anche nella distribuzione che sto usando io? Non per polemizzare, lo chiedo seriamente. In questo momento sto usando una distro basata su debian e metti caso che la combinazione di programmi che stanno usando ha delle falle di sicurezza. Come so che vengono corrette? Mi devo fidare.... che strano, è la stessa cosa che si fa con gli OS closed source!
[/quote]

Nessuna polemica, anzi, il tuo è un dubbio assolutamente legittimo.
L'Open Source ha un modello di buisiness strano anzi ne ha tanti, uno di quelli che preferisco è il seguente.
La comunità (io a casa e nel tempo libero) produce software (mi piace e mi diverte), che ovviamente non segue necessariamente una SQA line, non ha supporto, non ha garanzie di funzionamento, questo software se valido vine preso e inserito in un incubatrice da una o più grandi aziende che forniscono alla comunità (a me, che ora posso lavorare con grandi professionisti) altra forza lavoro a questo punto specializzatissima o strutture tecnologiche (sempre a me, che ora posso contare su un server repositry, gestore bug ed altre cose...).
In questa incubatrice si trovano i sistemi ed i metodi industriali, ad esempio i modelli di SQA, che permettono al software quando manuro di migrare (sempre come OSS) verso la distribuzione stabile.
Questa volta però, il software è corredato, sotto pagamento di una tot (che poi è il business dell'azienda in questione) delle garanzie utili per un uso business ed enterprise.
Queste garanzie possono essere le più svariate, dall'assicurazione contro il patent trolling, all'assicurazione del supporto per 10 anni o più e tante altre.
Cosa garantisce questo sistema? A mio avviso un paio di cosette non da poco, la prima è che una azienda a cui si rivolge per quanto grande non riuscirebbe mai a disporre di un reparto di R/D e di debuging delle dimensioni della comunità e quindi l'azienda può disporre di una grande fucina di idee e progetti con una ottima velocità di sviluppo e sopratutto un debugging accurato, la seconda che è fondamentale per il cliente pagante è il supporto, la garanzie e la qualità del prodotto fornite una azienda privata, che si rivela a questo punto l'unico interlocutore diretto.
Per me non c'è molto di meglio, una bella sinergia tra le persone e le aziende, un bellissimo equilibrio tra il business (che nel bene e nel male al momento è quello fa girare il mondo) e il sociale che poi è la fonte di crescita umana che abbiamo.
Ciao Paolo,

il video è un falso.

Deevtev lo ha conermato sul suo twitter https://twitter.com/#!/devteev/status/134538558588456960 inoltre c'è un bell'articolo completo su http://exploitshop.wordpress.com/2011/11/10/on-the-impossibility-of-ms11-083/ che spiega bene, anche se in maniera molto tecnica l'exploit.

Technet (http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx?utm_source=twitterfeed&utm_medium=twitter) lo spiega in maniera più semplice.

La base è che prima di eseguire la vulnerabilità si deve portare il counter dei pacchetti ad arrivare ad int_max (2^32 - 4294967296), quindi ci vogliono moltissimi pacchetti inviati.

Inoltre l'exploit deve essere eseguito con un buon timing e al momento corretto in cui l'overflow è stato appena raggiunto. Questo senza conoscere esattamente a che punto stà il counter della macchina da attaccare e senza che nessun altro invii altri pacchetti UDP diventa moooolto difficile.

Il video potrebbe essere preso come "esempio di exploit" se il "this may take a while" che c'è mentre manda i pacchetti duri un mesetto e fallisse una decina di volte al posto di una sola prima di riuscirci.

Inoltre come detto nell'articolo è una vulnerabilità che verrebbe bloccata dalla maggior parte dei firwall.

Rimane comunque da patchare ed è comunque rischioso. Anche se più per le potenzialità di DOS (Denial of Service) che come backdoor per prendere possesso di un computer.
Qualche correzione tecnica ai commenti per chiarire alcune cose sulla elevata criticità della vulnerabilità.
Avere un host firewall installato e correttamente funzionante sul pc non esclude la possibilità di essere vittima di un attacco su questa vulnerabilità perchè tutto dipende da come il firewall è configurato. Al firewall potreste anche aver detto di accettare del traffico UDP in ingresso per usufruire di qualche servizio importante, come potrebbe essere un servizio DNS, che lavora generalmente su protocollo UDP oppure il servizio di EMULE che tanto usate per scaricare materiale ovviamente non coperto da copyright.
Così, pure, la mancata esposizione su internet del vostro pc non impedisce che l'attacco possa essere sferrato da chiunque raggiunga a livello 3, cioè a livello ip o di instradamento dei pacchetti (routing), il vostro pc. Esempio, un vostro collega di lavoro sulla vostra stessa lan, ma anche su di un altra, nel vostro ufficio o un ufficio diverso ma interconnesso al vostro (intranet). Gli scenari di 'esposizione' o di 'raggiungibilità' del vostro pc nella dimensione digitale non corrispondo a quelli nella dimensione fisica.
[quote-"Il Lupo della Luna"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c3559068520032626384"] In questo momento sto usando una distro basata su debian e metti caso che la combinazione di programmi che stanno usando ha delle falle di sicurezza. Come so che vengono corrette? Mi devo fidare....
[/quote]

Ma cosa stai dicendo?

Vai a vedere i rilasci di sicurezza delle varie distribuzioni (certo, non quelle da cantinaro) e vedi come sono tutte corredate di codice CVE risolto e di quali patch sono state applicate, complete di puntamento al codice sorgente delle patch.
Il problema sono quelli che si credono sysadmin ma non lo sono e lasciano roba aperta a pigs&dogs&lizards (d.b. docet) la rete è piena di server configurati a cane...
@il lupo della luna
(scusa se ti rispondo a 10km di distanza dal tuo post)

Il fatto è che nel closed source non hai il sorgente a disposizione e quindi non sei in grado di valutare esattamente se il codice è buggato o no. Il fatto di avere i sorgenti in mano ti permette di VEDERE il codice e scoprire molto più facilmente vulnerabilità, bug, comportamenti scorretti, mentre nel closed source devi andare un po' a tentoni, e soprattutto sperare che mamma microsoft si decida a prendere atto del bug e lo corregga. Mentre la community in questo senso è molto attiva e soprattutto molto più veloce nel correggere un problema ;)
non sono un cracker né buono né scarso!
Che fame...
Palin: mettiamola in un altro modo che forse spiega meglio cosa intendo dire. Provo con un esempio: io sono un utonto che ha comprato un portatile con Linux perchè costava meno.
C'è anche un programma che verifica gli aggiornamenti e ogni tanto (almeno un paio di volte al giorno) mi dice che ci sono degli aggiornamenti da fare e io gli dico semplicemente di applicarli.

Qual'è la differenza tra questo approccio che ho appena esemplificato e quello di Microsoft o Apple?
Siamo in due!

Tre
Siamo in due!

Tre

Allora fiuuuuu al cubo :-)
@ martinobri: ma oggi è il tuo onomastico?
Guido: però a me utente finale (chi non ha idea di cosa sia un codice sorgente) il fatto che ci si possa "guardare dentro" e capire se è sicuro o no è totalmente ininfluente. E' comunque una cosa al di là delle compentenze dell'utente finale (e, son pronto a scommetterci, anche del sistemista medio). Per farla breve: ok che si può fare, ma non so quanti lo facciano.

Ma anche se ci capissi qualcosa, una volta che ho scovato un errore, me lo sono corretto e l'ho fatto presente a chi di dovere (presumo ci sia modo di contattare gli sviluppatori della distribuzione linux per queste cose) devo comunque aspettare che venga attuata una procedura per inserire la patch nel codice: dubito seriamente che si limitino a prendere la mia correzione e distribuirla. No, perchè se devo pure scaricarmi il sorgente, applicare la modifica e ricompilare tutto io e l'open source non andiamo affatto d'accordo. :)
Vai a vedere i rilasci di sicurezza delle varie distribuzioni (certo, non quelle da cantinaro) e vedi come sono tutte corredate di codice CVE risolto e di quali patch sono state applicate, complete di puntamento al codice sorgente delle patch.

OK, adesso ti faccio una domanda: hai controllato?
@ Claudio

"OT: ma avete sentito l'intervento di Paolo a Caterpillar AM questa mattina, sull'11/11/11? E soprattutto, Rob "Kazzenger" Giacobbo che si dichiara daccordo con Paolo e afferma che la numerologia è una boiata? E che nel 2012 non accadrà nulla (detto dall'autore di un libro di fuffa sul 2012...LOL!)?
Quell'uomo è un gran fuffaro, ma ha classe :)
Quando sa che non può vincere, cambia strategia."

Sai, onestamente io non penso che Giacobbo creda davvero a tutte le baggianate che vengono propinate nei vari servizi del programma che lui stesso conduce. Avevo visto una sua intervista (mi pare su La7 con la Bignardi) dove lasciava trasparire che in fondo riteneva plausibili soltanto alcune fra le tante congetture, ma che in pratica dava spazio a tutte, anche le più assurde, per stimolare la curiosità dello spettatore. Leggi: fare più ascolti. Il che ovviamente, dato che quello è il suo preciso lavoro, non è niente di intrinsecamente sbagliato. Ma è comunque terribilmente ed incommensurabilmente squallido da un punto di vista culturale ed educativo. Ancora una volta Angela docet: non c'è bisogno di dover ricorrere al paranormale per poter fare scalpore, il normale è già abbastanza incredibilmente meraviglioso (e talvolta un po' spaventoso), oltre ad essere spiegabile in modo oggettivo e coerente.
@Il Lupo della Luna
Qual'è la differenza tra questo approccio che ho appena esemplificato e quello di Microsoft o Apple?

Che se tu non sei in grado di verificare, c'è chi lo farà per te perché è disponibile la patch il suo sorgente e il diff file. Quindi, una finta patch può essere scoperta molto più facilmente che per in software chiuso.
Inoltre, il vantaggio principale di un software open source è la maggiore velocità di reazione per la risoluzione di un problema. Il rovescio della medaglia è che un codice sorgente di dominio pubblico rende più facile scoprire falle da parte un malintenzionato.
Quindi, al domanda che dovresti porre è: è meglio un software chiuso che rende più difficoltoso scoprire le falle a cui, però, si rimedia più lentamente, o meglio un software aperto le cui falle sono scoperte e turate con maggiore velocità?
OT: Su "Il fatto quotidiano" di oggi (11/11/11 complotto?) c'era un articolo su Paolo, solo che c'erano anche delle parti virgolettate, solo che non si capisce bene se sono frasi prese qua e là o parte di una intervista.
@Giuseppe
In realtà la difficoltà di trovare falle sfruttabili (che sono diverse dai bug! Attenzione, bug != falla) in un software open sono in realtà diverse (non minori o superiori) rispetto ad un software chiuso. Per il software open hai il vantaggio di avere il codice, ma QUANTE persone l'hanno già visionato? Invece il codice chiuso ha giocoforza una fase di test più limitata.

Comunque che le distribuzioni linux siano superiori a Windows non è solo questione di open e closed source, ma, tanto per dirne una, il sistema è molto più "separato a camere stagne". In Windows c'è quel mega-file che è il registro, cosa totalmente assente in linux che ha una miriade di file di configurazione, col risultato che se un programma si incastra ben più difficilmente incastra l'intero sistema. Senza parlare di altre cose come file system (persino Ubuntu ne offre una scelta Windows offre il solo NTFS che impone una deframmentazione per funzionare al meglio), permessi utenti (gestiti da cani sotto windows), ecc ecc.
Giuseppe: beh, a prescindere, meglio un sistema operativo che funzioni. :) E potrei aprire un blog con la lista delle distribuzioni linux che non hanno retto al primo aggiornamento..

Posso però risponderti dicendo che se la reazione lenta alle patch non mi crea problemi (ovvero se qualcuno non sfrutta prima le falle), preferisco la seconda opzione, perchè non è più lenta per pigrizia, ma per il ciclo di verifiche a cui la patch viene sottoposta e per la maggior professionalità che mi (si, beh, dovrebbe....) garantisce il fatto che i programmatori sono pagati e non volontari.
@Il lupo della Luna
...perchè non è più lenta per pigrizia, ma per il ciclo di verifiche a cui la patch viene sottoposta e per la maggior professionalità che mi (si, beh, dovrebbe....) garantisce il fatto che i programmatori sono pagati e non volontari.

Purtroppo, la maggior lentezza non è dovuta ad un maggior numero di test, ma è dovuta principalmente a due fattori:

1. i programmatori, per quanto grande possa essere un'azienda, sono di meno di un'intera comunità di programmatori, seppur a tempo perso e volontari

2. spesso, è la software house stessa che decide volontariamente di non risolvere una falla o un bug almeno finché non è pubblicata da qualcuno: turare le falle o correggere i bug costa.

Il fatto che i programmatori open source siano volontari non implica che facciano le cose in modo raffazzonato. In realtà il loro lavoro è regolato secondo gli stessi standard che vengono usati presso una classica software house.
La prova della bontà del lavoro nell'open source sta nel fatto che capita che intere parti di codice open source vengano integrate in software chiuso. Ad esempio Mac Os è strettamente imparentato con Linux (anche in questo caso Steve Jobs è stato un gran furbone: perché scrivere da zero il codice sorgente di un sistema operativo quando ce n'è già a disposizione uno funzionante? :-)); la Microsoft stessa, anche se non mi risulta che abbia mai copiato nel senso letterale del termine, ne ha attinto. Ad esempio, i sistemi operativi da Windows 2000 in poi, gestiscono i dischi eseguendo il mount del file sistem come fa Linux da sempre. Questo si nota durante l'installazione ma si può osservare anche nel fatto che si può cambiare a piacimento la lettera di un hard disk o, addirittura, gestirlo senza assegnargliela. Questo fino a Windows 98 era impensabile.
Quanto detto non significa comunque che la tua scelta sia sbagliata. A mio avviso il bilancio tra i vantaggi e gli svantaggi che portano l'open rispetto al closed è sostanzialmente in pareggio.
Trovato forum dove se ne parla diffusamente e tecnicamente....anche troppo!
http://www.reddit.com/r/netsec/comments/m52ex/ms11083_remote_kernel_exploit_via_crafted_udp/

Non ho letto tutto, ma mi par di capire che è un baco così imbecille da ricordare quelli degli anni '90 (ricordate i bei tempi in cui per entrare in un pc con windows 95 bastava leggerne l'IP su MIRC? :-) ): praticamente la porta "chiusa" non è "stealth": cioè, se "qualcuno bussa", uno da dentro risponde "qui non c'e' nessuna porta", o roba del genere. :-)
@lufo88
Ho usato il termine falla sia per indicare i bug che le falle vere e proprie. Più o meno come avviene oggi col termine virus informatico :-)

Comunque che le distribuzioni linux siano superiori a Windows non è solo questione di open e closed source, ma, tanto per dirne una, il sistema è molto più "separato a camere stagne". In Windows c'è quel mega-file che è il registro, cosa totalmente assente in linux che ha una miriade di file di configurazione, col risultato che se un programma si incastra ben più difficilmente incastra l'intero sistema. Senza parlare di altre cose come file system (persino Ubuntu ne offre una scelta Windows offre il solo NTFS che impone una deframmentazione per funzionare al meglio), permessi utenti (gestiti da cani sotto windows), ecc ecc.

E' vero.
La gestione mediocre dei permessi e della sicurezza nasce sia dal fatto che la Microsoft ha scelto di mantenere un'elevata compatibilità con i sistemi precedenti (ancora oggi si possono far girare molti programmi progettati per windows 95) sia per scelte commerciali: l'utente medio è pigro, allora non gli creo problemi anche a costo di inventarmi l'utente System, non accessibile normalmente, il vero equivalente (e non administrator come molti credono) di root delle distribuzioni Linux.

Ma ha ragione Il Lupo della Luna quando afferma che ci sono molti problemi con gli aggiornamenti di Linux, dovuti, a mio avviso, proprio alla separazione a camere stagne. Linux non possiede un registro dei programmi innstallati e relativa versione, quindi, il sistema operativo non sa cosa è installato e cosa no. I pacchetti di installazione sono gestiti da RPM o DEB e gli aggiornamenti possono usare come riferimento questi database che non sempre coincidono con quanto installato veramente. Da qui i "casini" con gli update.
Ecco perché ritengo che non ci sia un sistema superiore: i vantaggi di un sistema open source si pagano con degli svantaggi. Lo stesso vale per i closed source.
La scelta del sistema da usare deve essere funzione delle proprie esigenze e null'altro.
praticamente la porta "chiusa" non è "stealth": cioè, se "qualcuno bussa", uno da dentro risponde "qui non c'e' nessuna porta", o roba del genere. :-)

OMG, mi torna in mente il mitico post su Usenet "Turbamenti di una minorenne" di Leonardo Serni, del lontano 1999, proprio su questo argomento.
Obluraschi! ;-P
:)
un post un po' strano Paolo... di solito sei più preciso... sembra QUASI uno degli articoli un po' buttati lì che ci sono sempre su Punto Informatico...

ciao
@ martinobri: ma oggi è il tuo onomastico?

No, era ieri :-)
Grazie del pensiero,
[quote-"Giuseppe"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c1038812256315885716"]
[...]Linux non possiede un registro dei programmi innstallati e relativa versione, quindi, il sistema operativo non sa cosa è installato e cosa no. I pacchetti di installazione sono gestiti da RPM o DEB e gli aggiornamenti possono usare come riferimento questi database che non sempre coincidono con quanto installato veramente.
[/quote]

La realtà è esattamente il contrario di quanto affermi. I sistemi di gestione dei pacchetti tengono traccia non solo delle applicazioni installate, ma dell'esatta versione di ogni singola libreria presente nel sistema (purché ovviamente non installata manualmente). Chi non ha un sistema centralizzato di gestione del software installato è invece proprio Windows, il cui elenco di programmi (pannello di controllo => installazione applicazioni, se parliamo di XP) non fa altro che richiamare il programma di disintallazione dei singoli software.

Non confondere il registry di Windows, che non è altro che una spece di filesystem specializzato per le impostazioni di configurazione, con l'elenco dei programmi installati.
(Per la cronaca, anche Gnome ha adottato un sistema simile, cfr. gconf).
@lufo88

"Saturno" di venerdì 11:

www.ilfattoquotidiano.it/2011/11/11/io-cacciatore-di-balle-digitali/169947/

(sta in "archivio cartaceo", credo sia necessario essere registrati)

Sarei curioso anch'io di sapere se si tratta di un'intervista vera o ricostruita col taglia-e-cuci digitale.
Giuseppe, da quanto non metti le mani su una macchina Windows? ;p L'ultima release di NTFS non guadagna assolutamente nulla dalla deframmentazione, perchè è journaled, come EXT-4. Non devi nemmeno più fare scandisk a meno di crash epocali..

Il Registry in realtà non è UN file ma un "hive", composto da mezza dozzina di file diversi ed è strutturato come il db di configurazione di Gnome, che somiglia tanto al sistema Netinfo di Darwin/OSX; Darwin in realtà è molto meno imparentato con linux di quel che comunemente si dice, essendo basato sul BSD della fine degli anni '80 (quello della NeXT), quando Linux era ancora al di là da venire e c'erano solo sistemi UNIX commerciali. E BSD non è esattamente gestito da "non professionisti" dato che dietro c'è una delle maggiori università d'America, con controlli di qualità molto stretti (soprattutto per openBSD).

Insomma, non c'è poi molta differenza tra i vari sistemi operativi e dubito seriamente che un approccio sia intrinsecamente migliore di un altro. Ad esempio, la gestione dei privilegi utente di Windows è un paio d'anni luce avanti a quella di Linux per la "granularità" con cui ti permette di impostare i permessi.

Preparare una patch costa, è vero.
Non prepararla costa anche di più in termini di immagine, e aspettare che un exploit venga sfruttato non è una buona idea a lungo termine, ci sono ancora in giro per la rete dei pacchetti di Blaster che tentano di spengere macchine windows.

Spacesurfer: closed o stealth che sia, i pacchetti comunque arrivano alla porta, sta alla macchina dietro dire se sono rifiutati (closed) o ignorati (stealth). Se ricordo bene l'impostazione standard è che vengano rifiutati, così la macchina trasmittente li rimanda. Ho letto per curiosità il funzionamento del TCP/IP ma francamente non è il mio mestiere e non ci ho capito molto..

A quanto pare comunque la falla è "critica" come tutte quelle che permettono di eseguire codice indesiderato, ma richiede delle condizioni molto particolari: l'invio un numero spaventosamente alto di pacchetti "modificati" e SOLO di quelli alla macchina bersaglio. Il contatore dei pacchetti può andare in overflow e terminare il programma in CINQUE modi diversi, e solo uno permette d'eseguire il codice "parassita", gli altri vanno dal resettare il contatore e ricominciare normalmente ad un Denial of Service.
MR,

Sarei curioso anch'io di sapere se si tratta di un'intervista vera o ricostruita col taglia-e-cuci digitale.

Non l'ho ancora letta neanch'io, per cui non te lo so dire. Posso dirti che comunque la giornalista mi ha intervistato per circa un'ora.
Ecco che partono le tifoserie :-)
Ripeto: il sistema si sceglie in funzione delle proprie esigenze (a parte qualche sfigato come me che li deve usare un po' tutti)

@Lupo della Luna
@MR
I permessi di Windows, è risaputo, non sono granulari: sono confusionari e si sovrappongono. Ho fatto l'esempio dell'utente system. Normalmente ci si aspetta che l'utente administrator sia quello con i privilegi maggiori ma così non è: è l'utente system ad averli. Sempre a proposito di permessi, è possibile negare persino a system l'accesso ad un file, cartella o anche a chiavi di registro. Questo comportamento irrazionale entra sempre nella logica di Microsoft di accontentare il più elevato numero di utenti alla faccia della qualità e logica del sistema: ogni utente del pc pur essendo appartenente al gruppo administrator può negare l'accesso agli altri utenti, anch'essi administrators. L'utente root nei sistemi Linux invece ha accesso a tutto, indipendentemente dai permessi impostati. E' questo è l'approccio più logico.

In merito al "gestore di pacchetti" vs windows installer sono state dette delle imprecisioni.
Il gestore di pacchetti funziona fintanto che si utilizza rpm, deb et similia. Ci sono dei software anche per Linux che hanno un loro installer (spesso uno script come avviene, per esempio, con Firefox che comunque è disponibile anche "pacchettizzato"). Questi programmi risultano invisibili al gestore di pacchetti. Windows installer non è un semplice elenco di software installati. E' anch'esso un database ed è strettamente legato al registro. Le informazioni per la disinstallazione di ogni applicazione sono nel registro e gestisce le dll e anche le loro incompatibilità attraverso Windows Side by Side (Windows SxS). Anche per windows installer vale quanto detto per il gestore di pacchetti Linux, cioè, il software di installazione deve interagire col servizio windows installer; se non lo fa avviene quanto detto da MR, cioè, il programma è installato/disinstallato attraverso il suo installer. Questo lo si osserva quando si lavora in modalità provvisoria: i programmi installati mediante windows installer non si possono disinstallare in tale modalità, gli altri sì.

Lupo della Luna, per quel che riguarda scandisk, EXT4 è di molte spanne sopra NTFS. Perché NTFS è journaled di nome ma non di fatto. Infatti, per EXT4 scandisk serve, per lo più a cercare settori danneggiati nel disco. Prova a togliere l'alimentazione a un pc con Windows in fase di arresto: se sei sfortunato al successivo avvio avrai la schermata blu con l'errore "unmountable boot volume", se sei fortunato, l'errore lo otterrai dopo una decina di spegnimenti "brutali".
Infine, hai ragione sul danno d'immagine per un ritardo di pubblicazione di una patch: ma lo fanno lo stesso. Forse per loro conta di più "il risparmio oggi del maggior danno domani"
Aaarghhh! Ho scritto spece. Senza i.

Mannaggia li tasti...
[quote-"Adriano Esposito"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c5599247884568460561"]
OK, adesso ti faccio una domanda: hai controllato?
[/quote]

Sai, avendo dovuto ricreare pacchetti rpm binari applicando a mano la patch, ti posso rispondere che per alcune patch di sicurezza, ho controllato personalmente, sia che il binario non patchato fosse vulnerabile, sia che quello patchato lo fosse.
[quote-"Il Lupo della Luna"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c7367784461071655973"]
Guido: però a me utente finale (chi non ha idea di cosa sia un codice sorgente) il fatto che ci si possa "guardare dentro" e capire se è sicuro o no è totalmente ininfluente.
[/quote]

Se è per questo io non posso neppure entrare nella centralina della mia macchina per sapere se il meccanico mi ha fatto la riparazione a regola d'arte... oppure non posso certo sfondare il muro di casa per vedere se la coibentazione è corretta. Ma che c'entra? è ovvio che per fare le cose serve competenza: forse sugli stereo hifi l'utente finale rileva la risposta in frequenza del preamp perché non si fida dei dati dichiarati dal produttore?
@Giuseppe.

Ebbene sì, sono un tifoso :-)

Rileggendo quanto hai scritto alla luce del tuo ultimo commento, penso di aver capito meglio quello che intendevi parlando di Linux: se l'utente installa uno o più software senza utilizzare la versione pacchettizzata, il sistema di gestione dei pacchetti -appunto- non lo viene a sapere, quindi si crea una incongruenza. In questo scenario vale (anche se un po' imprecisa) la tua frase "gli aggiornamenti possono usare come riferimento questi database che non sempre coincidono con quanto installato veramente."
@Palin

Conosco gente che ha fatto il reverse engineering di intere DLL alla ricerca di bug, ma ciò è ininfluente. Sia loro sia tu non siete in grado di dichiarare l'assenza di bug nel codice, non siete neanche in grado di dichiarare se una patch introduce o meno nuovi bug. Neanche se la studiate.

La mia domanda intendeva sollevare la questione della falsa sicurezza che si può provare usando software open source.
[quote-"Adriano Esposito"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c2890278116676876284"]La mia domanda intendeva sollevare la questione della falsa sicurezza che si può provare usando software open source.
[/quote]

Un nuovo bug non significa per forza una peggiore sicurezza. E il senso di "falsa sicurezza" in questo caso tocca più i sistemi Apple (da cui sto digitando) che altro: basta guardare il plauso che ha ottenuto Little Snitch che può essere bypassato facilmente in modo programmatico.

Prima devo avere un setup ragionevolmente sicuro (ovvero che sia sicuro senza rendere inusabile il tutto come UAC), e poi se il sistema è open, tanto meglio così più occhi vigilano su dove sta il problema. Quando dico più occhi, non dico di tutti, dico degli esperti.

Dopo parecchio tempo che uso windows, sebbene non ne sappia molto degli internals, sono comunque riuscito ad avere un sistema piuttosto sicuro.

Certo se posso non lo uso :)
UAC su 7 è invasivo esattamente come la richiesta di password su Gnome (che scassa le balle ad ogni connessione di rete, windows lo fa praticamente solo se installi roba) o OSX quando stai usando un utente standard senza privilegi amministrativi (cosa che dovresti fare sempre)..
@Il Lupo della Luna:
Veramente a me la password di root (ad essere precisi la password del sudoer) viene chiesta sono quando devo fare qualche attività amministrativa.
Ho decine di reti configurate e mai mi vine chiesta la password di root.
Mi sa che forse c'è qualche flag "disponibile per tutti gli utenti" sul "NetworkManager" che non hai messo :D (caspita ora pure su Linux dico di mettere i flag... s'è proprio windowsato...)

Comunque quoto "tecnicamente" chi afferama che il sistema operativo migliore è quello che funziona e aggiungo "per il compito specifico".

Il mio punto di vista però non si limita all'aspetto tecnico o commerciale, ma poiché il coputer è la mia interfaccia verso le informazioni e l'interazione col mondo digitale il mio pensiero non può prescindere dalla filosofia con cui accedo a questo mondo o produco queste informazioni.
Per me,l'OSS, olre gli indubbi vantaggi tecnici e commerciali che "IO" ci vedo, colgo anche un discorso di orizonti. L'OSS mi permette in potenza la libertà totale di fare quello che desidero.
Mi accade anche quando sono in vetta ad una montagna o guardo un celo stellato, ammiro l'orizonte sconfinato e mi sembra che tutto sia possibile e che il futuro si li a portata di mano.
Questo futuro magari non sarà il mio ma sta lì, qualcuno lo coglierà e costruirà un mattoncino anche per me.
La stessa cosa non la vedo nel "closed source", mi sembra di essere in una specie di centro commerciale, una enorme scelta ma finita...c'è quello che è previsto da altri e alla fine c'è la porta che mi dice "Accesso consentito ai soli addetti ai lavori", ed ecco che il mio orizonte è finito.
@Giuseppe: L'utente root nei sistemi Linux invece ha accesso a tutto, indipendentemente dai permessi impostati. E' questo è l'approccio più logico.

Io non credo sia l'approccio più logico, personalmente è un approccio che non mi piace, e dal punto di vista della sicurezza è comunemente ritenuto molto pericoloso ed uno dei punti deboli del mondo Unix.
Windows ti lascia molta più libertà da questo punto di vista, è più coerente, e permette di dare ad ogni utente e/o sistemista soltanto il ruolo di cui ha bisogno, inoltre se noti su Windows non hai bisogno di accrocchi pericolosi quali setuid root per far funzionare un programma...
@Federico
...inoltre se noti su Windows non hai bisogno di accrocchi pericolosi quali setuid root per far funzionare un programma...

Come volevasi dimostrare :-)
Windows per "semplificarti" la vita utilizza il setuid ma fa in modo di non dartelo a vedere.

Un esempio? Tutti i servizi essenziali di windows lavorano con l'identità administrator quando non è proprio system. Se esegui services.msc dal prompt dei comandi e visualizzi i dettagli relativi ad un servizio, alla voce "connessione" trovi la voce quasi sempre spuntata "account di sistema locale", cioè utente system. Non ti far ingannare dal termine connessione che non si riferisce a connessioni di rete ma a che livello il servizio si deve interfacciare col kernel del sistema operativo.
Questo è proprio la metodologia di funzionamento del setuid di Linux. Tieni presente che un sistema operativo che gestisca la multiutenza non può prescindere da comandi del tipo setuid altrimenti, nella migliore delle ipotesi, gli utenti con privilegi limitati non sarebbero in grado neppure di accedere alla tastiera.

Precisazione: Linux non ha bisogno di setuid per eseguire un programma. Di solito, setuid serve per i daemon e per qualche programma che deve avere qualche privilegio in più per accedere, ad esempio, al modem. E anche in quest'ultimo caso non si utilizza setuid root ma si imposta un utente specifico che ha diritti di accesso al dispositivo modem e si fa girare il programma con l'uid relativa a quell'utente speciale.

Più razionale di così non si può. :-)
@Federico
Scusa ma il tuo commento è privo di fondamento e denota una non conoscenza dei sistemi di permessi *nix.
A parte che il suid da un problema se è producibile un buffer overflow, cosa che non è sempre così banale.
Ma sui sistemi *nix non devi essere obbligatoriamente root per fare le cose, dipende SOLO da come vengono configurati e da come "TU" sistemista, amministratore di sistemi decidi che debbano essere configurati.
Se hai voglia puoi anche montare i fs in sola lettura ed il sistema funziona uguale, ma non muovi una paglia, al limite puoi anche andare "all in ram"...
Puoi decidere quello che vuoi, basta farlo, se poi vuoi puoi implementare le policy lo fai con SE Linux (se usi GNU/Linux) o quello che preferisci.
Non conosco bene Win7 ma fino a poco tempo fa sui sistemi di casa microsoft l'utente doveva essere amministratore per poter masterizzre un CD (accedere ad un deivce).
Ma se non erro ora è stato rimosso il problema, meno male!
Certo la granularità di win è fantastica, ma mi è capitato di avere tecnici Microsoft (dipendenti di Microsoft) che non riuscivano a capire perché certe cose strane accadevano, proprio a causa di quella granularità e a causa dell'utente system, che è più forte di Administrator.
Altro esempio, un mount di un filesystem fatto da un programma, se il programma va in crash mentre gira come system (perché così ti ha detto mamma MS), ti trovi il mount appeso... bello, devi "trasformarti" in system e sganciare con alcuni barbatrucchi il disgraziato mount... che neanche il sistema operativo vede...ma c'è...
Troppe e dico TROPPE volte mi è capitato di dover, obtorto collo, permettere accessi amministratore agli utenti per far funzionare quel "dannato programma di terze parti" cosa che con dei client *nix non mi è mai capitato.
Non parlo del computer di casetta, quello della mamma o dello studiolo commerciale vicino di casa, dove l'utente fa quello che vuole, ma parlo di realtà da 3000/4000 utenti in su, realtà stratificate e incastrate da decenni di IT management!
Come ho già detto, anche con Windows, si possono fare cose, nessuno lo nega, ma devi farle bene, molto bene, talemnte bene che sono pochissimi quelli che le sanno fare... e devi mantenerti all'interno di HCL/SCM, guideline strettissime, talmente strette e comandate ( e costose) che a volte ti domandi... ma è un sistema così elastico come mi hanno detto quando me lo hanno venduto? Poi sei costretto a risolvere, con un software di terze parti, che sopperisce a difficoltà, errori di progettazione del sistema e simili amenità.
E che non mi raccontassero balle sulla retrocompatibilità! Neanche tra SP diversi sono compatibilli! Per non parlare delle interfacce utente o programma, ad ogni uscita di win cambiano gli switch di configurazione delle CLI, cambiano le diciture delle icone, le posizioni, le api, ora hanno pure separato CLI e GUI... pure i WWN mi hanno cambiato con un aggiornamento!
Non voglio demonizzare nessuno, quello che affermo con veemenza è che non è tutto rose e fiori e che non sempre quello che dicono è realmente attuabile, spesso è solo pubblicità e ancor più spesso tanti strumenti nel coltellino multiuso lo rendono inutile http://tiny.cc/17yzo, fai una cosa, falla bene.
@ martinobri: ma oggi è il tuo onomastico?

No, era ieri :-)
Grazie del pensiero,

Commento #78 – 12/11/11 14:31

Veramente io te l'avevo chiesto "ieri" :-) e comunque sul forum t'ho fatto pure gli auguri :-D
Precisazione: Linux non ha bisogno di setuid per eseguire un programma. Di solito, setuid serve per i daemon e per qualche programma che deve avere qualche privilegio in più per accedere, ad esempio, al modem. E anche in quest'ultimo caso non si utilizza setuid root ma si imposta un utente specifico che ha diritti di accesso al dispositivo modem e si fa girare il programma con l'uid relativa a quell'utente speciale.

È la stessa cosa che hai descritto poco sopra. Ho penso che NT Authority sia l'account personale di Bill Gates? :D



Built-in account. You can choose from a list of the following built-in Windows service accounts:

Local System account. The name of this account is NT AUTHORITY\System. It is a powerful account that has unrestricted access to all local system resources. It is a member of the Windows Administrators group on the local computer, and is therefore a member of the SQL Server sysadmin fixed server role

Security Note:
The Local System account option is provided for backward compatibility only. The Local System account has permissions that SQL Server Agent does not require. Avoid running SQL Server Agent as the Local System account. For improved security, use a Windows domain account with the permissions listed in the following section, "Windows Domain Account Permissions."

Network Service account. The name of this account is NT AUTHORITY\NetworkService. It is available in Microsoft Windows XP and Microsoft Windows Server 2003. All services that run under the Network Service account are authenticated to network resources as the local computer.

Security Note:
Because multiple services can use the Network Service account, it is difficult to control which services have access to network resources, including SQL Server databases. We do not recommend using the Network Service account for the SQL Server Agent service.
Veramente io te l'avevo chiesto "ieri" :-) e comunque sul forum t'ho fatto pure gli auguri

Ehm, era una battuta :-)
Grazie, però il forum proprio non riesco a frequentarlo :-(
@Palin
ovvero che sia sicuro senza rendere inusabile il tutto come UAC

@Lupo
UAC su 7 è invasivo esattamente come la richiesta di password su Gnome

Ai più paranoici non piace lo UAC di Windows Cucùsettete non perché è troppo invasivo, ma perché non è abbastanza invasivo: temono che si possano ripetere problemi come questo bug, in cui un tentativo di elevazione dei privilegi NON veniva sgamato dallo UAC di Cucùsettete con impostazione di default, ma veniva effettivamente sgamato dallo UAC se impostato "in stile sVista".

Il problema dello UAC è che, sia che venga impostato in "stile Cucùsettete" sia in "stile sVista", è solo l'ennesima finestra "Si/No" propinata all'utente. Come ci ricorda David Samuel Platt in "Perché il software fa schifo", dopo un po' per l'utente (non solo per l'utonto) la pressione su "Si" diventa quasi automatica.
Meglio sarebbe se Windows ti facesse entrare di default come utente NON privilegiato e poi UAC ti chiedesse la password dell'utente amministratore, un po' come in Linux (non stiamo a pedantizzare sul fatto che Linux ti ri-chiede la tua password, mentre Windows la password di un altro utente, con più privilegi). Forse anche digitare una password rischia di diventare meccanico, ma di sicuro meno che premere semplicemente su "Si".
Il problema è che all'utente quadratico medio già non piace quella finestra che gli chiede di cliccare "Si", figurati una richiesta di password!
@Federico
inoltre se noti su Windows non hai bisogno di accrocchi pericolosi quali setuid root per far funzionare un programma

Noooooooo, assolutamente... Certo, se usi su Windows Cucusettete programmi appositamente progettati per Windows Cucusettete, non ne hai bisogno. Ma il mondo non è fatto solo di software nuovo, ma anche di software cosiddetto "legacy" che sarebbe stupido buttare via, ma che, essendo progettato per i vecchi sistemi, non funziona senza un bel "esegui come amministratore", cioè grossomodo l'equivalente di setuid root.

Poi succede anche di peggio. Per una certa suite di prodotti software.... così, per sentito dire da mio cuggino... (metto il dito nel colletto in stile Al Capone)... gli Ordini dall'Alto ai programmatori sono: "Solo i moduli così e cosà (5-10% della suite) vanno revisionati in modo da funzionare su Windows Cucusettete con UAC abilitato. Per tutti gli altri moduli, dovete supportare Win 2008 e Windows Cucusettete MA PRESUMENDO UAC COMPLETAMENTE DISABILITATO"...


@Adriano Esposito
The Local System account option is provided for backward compatibility only. The Local System account has permissions that SQL Server Agent does not require

"backward compatibility" un par di trackball! Forse SQL Server Agent non ne ha bisogno, ma mi è capitato un caso (non ricordo esattamente lo sceMario, se era Win 2008 o Cubusettete) in cui non c'era verso di far andare il SQL Server Database Engine come Local Service o Network service, o Local System o ciccia.




@lufo88
permessi utenti (gestiti da cani sotto windows
@il lupo della luna
Ad esempio, la gestione dei privilegi utente di Windows è un paio d'anni luce avanti a quella di Linux per la "granularità" con cui ti permette di impostare i permessi.
@Giuseppe
I permessi di Windows, è risaputo, non sono granulari: sono confusionari e si sovrappongono

I permessi sui file Unix-like sono indubbiamente molto più semplici ed eleganti delle Access Control List di Windows, ma come si fa, ad esempio, a impostare un file con "a me tutti i permessi, permessi di lettura per Mario, Luigi e Tizio, permessi di lettura/scrittura per Pippo, Pluto e Caio, niente per gli altri" ? C'è solo "padrone, gruppo, tutti", e un file non può appartenere a più di un gruppo... qualcosa mi sfugge? Non sono molto esperto di sistemi Unix-like :(
Manuel
spesso è solo pubblicità e ancor più spesso tanti strumenti nel coltellino multiuso lo rendono inutile http://tiny.cc/17yzo

ROTFL-issimo!
Beh, almeno lì il coltello c'è: certi software a volte sono come un "coltello mille usi tranne quello di coltello"!
chi nasce quadratico muore quadratico caso van :D
[quote-"Federico"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c857118449501835466"]
Precisazione: Linux non ha bisogno di setuid per eseguire un programma. Di solito, setuid serve per i daemon e per qualche programma che deve avere qualche privilegio in più per accedere, ad esempio, al modem. E anche in quest'ultimo caso non si utilizza setuid root ma si imposta un utente specifico che ha diritti di accesso al dispositivo modem e si fa girare il programma con l'uid relativa a quell'utente speciale.

Più razionale di così non si può. :-)
[/quote]


Giusta precisazione... :D
[quote-"Van Fanel"-"http://attivissimo.blogspot.com/2011/11/falla-nel-tcpip-di-windows-permette-di.html#c7623751039292480994"]
I permessi sui file Unix-like sono indubbiamente molto più semplici ed eleganti delle Access Control List di Windows, ma come si fa, ad esempio, a impostare un file con "a me tutti i permessi, permessi di lettura per Mario, Luigi e Tizio, permessi di lettura/scrittura per Pippo, Pluto e Caio, niente per gli altri" ? C'è solo "padrone, gruppo, tutti", e un file non può appartenere a più di un gruppo... qualcosa mi sfugge? Non sono molto esperto di sistemi Unix-like :(
[/quote]

Potresti provare con getfacl e umask, a livello di file in sistema multiutente.

Poi dipende cosa devi fare, samba permette una grande elasticità.
Oppure puoi usare sistemi di versioning o documentali, ci vuole poco per tirar su un discreto documentale.
@Van Fanel

Ti giro anche un link che può essere utile:
http://a2.pluto.it/a2227.htm
@Van Fanel
I permessi sui file Unix-like sono indubbiamente molto più semplici ed eleganti delle Access Control List di Windows, ma come si fa, ad esempio, a impostare un file con "a me tutti i permessi, permessi di lettura per Mario, Luigi e Tizio, permessi di lettura/scrittura per Pippo, Pluto e Caio, niente per gli altri"

Non nego che una soluzione sarebbe un po' macchinosa del tipo dare la stessa uid agli utenti con i permessi di lettura/scrittura, creare un gruppo per quelli che hanno solo il permesso di lettura e negare l'accesso agli altri. Oppure per chi deve solo leggere può avere il suo buon pdf :-)
In altre situazioni, tipo un database, può essere il motore del database a implementare i permessi necessari.
Ma, francamente, quante volte ci si trova in situazioni del genere? E', invece molto più probabile trovarsi con il voler consentire l'accesso ad un file a Caio e non riuscire perché c'è una policy da qualche parte che l'accesso lo nega.
A mio avviso la Microsoft, anziché razionalizzare i permessi (anche ampliandoli rispetto a linux) li ha "sovradimensionati".
E' come se avesse costruito un tavolo con 18 gambe. Alla fine ne bastano 3 perché stia in piedi. Se lo si vuole far cadere si toglie una gamba e il gioco è fatto.
Per il tavolo Microsoft dovremmo togliere 16 gambe col rischio di farlo cadere dalla parte sbagliata :-)

@Manuel
quella precisazione è mia ;-)
@Giuseppe: Windows per "semplificarti" la vita utilizza il setuid ma fa in modo di non dartelo a vedere.
La mia impressione è che setuid sia stato inventato per aggirare una limitazione del sistema, che di fatto riconosce un solo utente root in grado di avere il controllo completo sulla macchina.
Limitazione che su Windows non esiste, tanto è vero che, come dici tu qualche post più in alto, puoi addirittura limitare i privilegi sull'utente di sistema. Nelle mani sbagliate questo può creare un sistema incoerente e non funzionante, ma nelle mani giuste è uno strumento molto potente.
D'altra parte, nonostante tutti ritengano il contrario, Unix non è nato con la sicurezza in mente ma la sicurezza è stata aggiunta in seguito, e secondo me si vede eccome. Windows NT (lasciamo stare la famiglia consumer) invece è stato progettato fin da subito per essere sicuro. Strano no? In realtà non c'è nulla di strano è nulla da stupirsi, NT è stato progettato almeno 20 anni dopo il primo Unix...

E anche in quest'ultimo caso non si utilizza setuid root ma si imposta un utente specifico che ha diritti di accesso al dispositivo modem e si fa girare il programma con l'uid relativa a quell'utente speciale.

Bene così, ma perché usare un utente che non è un utente, quando su Windows avresti usato un gruppo con delle ACL apposite?
Non sto dicendo che su Windows sia più semplice, anzi probabilmente non lo è.
Ma qui non sto parlando di che cosa sia più pratico o semplice, sto invece facendo pura filosofia informatica, ed usare un utente che non è un utente per me è una grossa incoerenza :-p

Non ho tempo di rispondere a tutti i commenti che riguardano il mio post (anche se sono molto interessanti).

In ambiente Unix vedo perà un grosso problema. Come ci si comporta quando un server (on un insieme di server) è gestito non da un unico sistemista, ma da un gruppo di sistemisti, con ruoli e privilegi diversi? Magari nemmeno dipendenti della stessa azienda? Bisogna scambiarsi la password di root?
E se uno dei sistemisti non deve avere accesso a tutto il sistema, ma soltanto ad una parte?
Su Windows è complesso, ma sei potenzialmente in grado di distinguere con precisione i ruoli di più sistemisti diversi. Su Unix come si fa?
@Giuseppe: Ma, francamente, quante volte ci si trova in situazioni del genere?

a me, ad esempio, succede ogni giorno, e spesso ci sono combinazioni di permessi mooolto più complicate.... dio benedica le ACL e NTFS :-)
@Giuseppe
Hai ragione, ho i quote che mi funzionano a cavolo, dopo un certo numero di commenti il tasto "quote" mette in memoria il commento precedente, nel tuo non ho c'ho fatto caso. :P
@Manuel: Wow! grazie! Tutti i testi che ho letto sul mondo *nix parlavano soltanto dei "permessi classici".
Secondo i miei calcoli, la mia abissale ignoranza linuxiana è appena diminuita dello 0,00001% ! :D

@Giuseppe: a volte mi chiedo se il tavolo Microsoft è in coproduzione con Ikea...
@Van Fanel
Di nulla! Son felice di aver contribuito a quello 0,00001 :)
Ricorda che il filesystem a cui applichi le ACL deve essere montato con le ACL attive, in fstab qualche cosa del tipo:
/dev/sdbN /MioMountPoint ext3 user,noauto,acl 0 0

e che siano supportate dal kernel che usi, ma ora lo sono quasi tutti.

P.S. Poiché immagino che il mountpoint sia usato da tanti utenti, se vuoi impedire l'eventuale esecuzione di file puoi intervenire sempre in fstab con un bel noexec.

Ringrazio Paolo di aver ospitato questo piccolo scambio :D
@Federico
Secondo me Windows e i sistemi Unix-Like hanno avuto approcci differenti dovuti anche all'origine differente dei due sistemi operativi. Unix è nato nelle università e, quando sono stati implementati i permessi (ben prima di Windows NT for workgroup) l'origine universitaria (in particolar modo l'impostazione matematica) si è fatta sentire: si è stabilito un numero minimo di opzioni a partire dalla quali si poteva creare un sistema di permessi più complesso. Windows ha avuto un approccio opposto, di stile ingegneristico (gli ingegneri non me ne vogliano, è un modo di dire):
mi serve una cosa? l'aggiungo senza stare a pensare se è una ridondanza.

Gli utenti e gruppi fittizzi, in realtà, sono una prerogativa di Windows (vedi system o network access group) e fanno parte degli stratagemmi che si usano per evitare che il sistema resti gestibile solo a livello di amministratore. Contrariamente alle apparenze, Linux non utilizza utenti e gruppi fittizi. L'utente specifico che ho menzionato a proposito della gestione del modem è un normale utente a cui, semplicemente perché non necessaria, non si assegna alcuna shell di accesso. Questo ne aumenta anche la sicurezza.
Quindi gli utenti di Linux si riassumono in due gruppi: root e tutti gli altri.

In ambiente Unix vedo però un grosso problema. Come ci si comporta quando un server (on un insieme di server) è gestito non da un unico sistemista, ma da un gruppo di sistemisti, con ruoli e privilegi diversi? Magari nemmeno dipendenti della stessa azienda? Bisogna scambiarsi la password di root?
E se uno dei sistemisti non deve avere accesso a tutto il sistema, ma soltanto ad una parte?
Su Windows è complesso, ma sei potenzialmente in grado di distinguere con precisione i ruoli di più sistemisti diversi. Su Unix come si fa?


Esiste anche nei sistemi Unix il gruppo root ed esistono metodi di autenticazione centralizzati in grado di gestire le credenziali e privilegi di più server contemporaneamente. Alcuni di questi sistemi permettono anche di gestire l'autenticazione in sistemi misti Windows/Linux (Kerberos ad esempio).
In ogni caso vale quanto detto da me all'inizio: si fa un quadro delle proprie esigenze e si adotta il sistema che ne soddisfa quelle maggiormente rilevanti.

Nel tuo caso è probabile che Windows sia comunque più comodo :-)

Come già detto, ognuno dovrebbe focalizzare le proprie esigenze e scegliere quello che soddisfa le più rilevanti o il maggior numero.

Io uso Windows, Linux e Leopard (anche virtalizzati), pur non essendo un vero sistemista, perché fa parte del mio secondo incarico non ufficiale (pagato con i "mille grazie" al mese citati in passato) nella mia azienda e mi ha permesso di superare la crisi senza il rischio di essere "messo in ferie".

@Van Fanel
a volte mi chiedo se il tavolo Microsoft è in coproduzione con Ikea...

No: le istruzioni di Ikea sono molto più precise e intelligenti :-)
@Federico
Mi rendo conto che il termine "utente specifico" utilizzato nel post #93 possa far pensare ad utenti speciali o fittizi. Colpa mia :-)
@Giuseppe
Quotone! :D

P.S.
"No: le istruzioni di Ikea sono molto più precise e intelligenti :-) "
Aggiungo, le istruzioni di Ikea, se seguite, portano sempre al risultato voluto. :P