skip to main | skip to sidebar
83 commenti

ShellShock: falla critica in Linux, Mac OS X e altri sistemi operativi derivati da Unix

L'articolo è stato aggiornato estesamente dopo la pubblicazione iniziale.

C'è una falla seria in innumerevoli server, computer, router, dispositivi connessi a Internet che permette agli aggressori di agire in modo così  devastante che l'ente statunitense NIST ha assegnato a questa vulnerabilità il massimo grado di gravità: dieci su dieci.

Non c'è da stupirsi, dato che la falla, battezzata ShellShock, consente per esempio di prendere il comando di un server Web non aggiornato semplicemente mandandogli un solo comando via Internet.

Secondo l'esperto Robert Graham di Errata Security, ShellShock è sfruttabile per creare un attacco che si autopropaga: “this thing is clearly wormable”. Una sua scansione ha già trovato alcune migliaia di server vulnerabili, e la BBC parla di mezzo miliardo di dispositivi a rischio. È già in circolazione il primo malware basato su ShellShock (Virustotal; Kernelmode.info) e Trustedsec ha pubblicato una dimostrazione di come questa falla può essere usata per attaccare un computer o altro dispositivo Linux vulnerabile che si collega a una rete Wi-Fi ostile.

Niente panico, comunque: gli utenti Windows sono totalmente immuni dalla falla, a meno che abbiano installato software come per esempio Cygwin: il problema, infatti, riguarda i dispositivi che usano sistemi operativi “Unix-like”, come per esempio Linux, Mac OS X o iOS. Al momento i Mac risultano formalmente vulnerabili, ma la falla normalmente non è sfruttabile per attacchi dall'esterno se si usa il Mac come workstation (per chi lo usa come server pubblico è tutta un'altra storia). Inoltre gli antivirus riconoscono già questo genere di malware. Se volete sapere se un sito è vulnerabile, c'è un test innocuo presso Brandonpotter.com.

È comunque fondamentale aggiornare i dispositivi vulnerabili installando la correzione (e anche la correzione della correzione), che è quasi sempre già disponibile: un'operazione relativamente facile per i computer, ma chi aggiornerà router, webcam, termostati, smart TV, stampanti, NAS e altri dispositivi online? Improvvisamente l'Internet delle Cose non sembra più una bell'idea come prima.


In dettaglio


La falla (CVE-2014-6271) risiede in Bash, l'interprete dei comandi di quasi tutti i sistemi operativi Unix e “Unix-like”. Secondo alcune indicazioni, giace indisturbata da circa vent'anni: un fatterello che non mancherà di riaprire il dibattito sui pro e contro dell'open source in termini di sicurezza (sul quale dico subito che la falla è stata scoperta proprio perché il codice sorgente è ispezionabile e che non sappiamo quante altre falle segrete ci sono nel software chiuso). È presente fino alla versione 4.3 inclusa ed è stata resa pubblica da Stephane Chazelas.

Per sapere se un dispositivo che usa Unix o simile (quindi anche un computer Apple) è vulnerabile, provate a digitare in una finestra di terminale questo comando:

env x='() { :;}; echo vulnerabile' bash -c "echo prova"

Se vi compare un messaggio d'errore del tipo bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
, siete a posto. Se invece compare la parola vulnerabile, siete appunto vulnerabili. Se comunque non vi va di attendere che Apple turi la falla, ci sono delle soluzioni non ufficiali qui.

Maggiori dettagli tecnici sono su The Register, Redhat.com, SlashdotArs Technica, e una delle migliori spiegazioni è quella di Troyhunt.com; in italiano c'è Siamogeek.
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 (83)
e l'iphone 6 che si piega è una vulnerabilità software o hardware ?
Paolo, sebbene Linux e la famiglia Unix abbiano lo stesso aspetto e comportamento non sono esattamente la stessa cosa. Inoltre Linux sarebbe il solo kernel mentre il resto dei programmi accessori si chiama GNU, e il sistema operativo GNU/Linux, che sarebbe l'acronimo di GNU's Not Unix.
Come hai scritto sotto, il problema è nella shell bash, la più comune ma non l'unica.
Ubuntu 12.04 LTS

Ho provato subito ed era fallato,
ho aggiornato (apt-get update && apt-get upgrade) ed adesso quel comando da errore!
Io non sarei allarmato per quanto riguarda i sistemi embedded.
Di solito viene usato Busybox (http://www.busybox.net/) che include una shell minimale e non la Bourn Again SHell.
Grazie della info. Lo ho provato anche con il mio cellulare aggiornato ad Android 4.4.4 (Cyanogenmod) e ne è affetto.

Come faccio però a vedere se invece il mio router ne è affetto?

Grazie.
Ho subito provato su Ubuntu 14.04 e la falla c'era. Poi ho lanciato un aggiornamento di sistema che ha scaricato la versione patchata. Ora sono a posto.
Segnalo che su *Ubuntu 14.04 l'aggiornamento di bash alla versione 4.3-7ubuntu1.1 ha fissato il bug.
Qui l'annuncio: https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-September/002674.html

Ciao!
Ciao.

Ho provato la linea di codice shell e anche la mia macchina LInux con su una Mint 17 aveva la falla. Ho provveduto a fare un "sudo apt-get update" seguito da "sudo apt-get upgrade" e il giochino non funziona più e restituisce un errore.

Per sicurezza sto facendo gli aggiornamenti anche sui server aziendali che hanno su Linux, anche se praticamente nessuno è esposto direttamente ad Internet.... ma non si sa mai quando si tratta di sicurezza.. ;-)

Grazie mille per la segnalazione! ;-)

J.
Hai lasciato il "$" della user session nello script.

Confermo, purtroppo la vulnerabilità, anche su sistemi recenti, Centos 6, ad esempio, oltre che su nas e apparati assortiti.
Vado a testare un paio di firewalll... ;-)
Suppongo che "oggetti" che non abbiano bisogno di interazione diretta con la shell semplicemente non abbiano bash installato. Ora è pure vero che quasi tutte le shell sono compatibili con bash ma non so se quella vulnerabilità è valida anche altrove.
Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-36-generic x86_64)

Dopo tutti gli aggiornamenti:

root@ubuntu# env x='() { :;}; echo vulnerabile' bash -c "echo prova"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
prova

Ce' "prova" ma non "vulnerabile". Il baco a che punto è con questa risposta?
Mi correggo: nell'ultimo link che hai messo c'è scritto:

You can determine if you are vulnerable by executing this test:

$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

The above output is an example of a non-vulnerable bash version. If you see the word vulnerable in the output of that command your bash is vulnerable and you should update.

Quindi *solo se* si vede la parola "vulnerabile" si è vulnerabili.
Patch arrivata su Ubuntu 14.04.
Brain, il comizietto,

grazie delle correzioni, ho sistemato.
Non mi è chiara una cosa; se le mie shell sono esposte solo tramite ssh sono comunque a rischio se ho un sistema vulnerabile?
Intendo dire, se uno non supera ssh non arriva su bash per attivare l'attacco no?
Nel mio ricevitore digitale DM800se:

root@dm800se:~# env x='() { :;}; echo vulnerabile' bash -c "echo prova"
prova

quindi non vulnerabile.
Il fatto che non appaiano i messaggi di errore non è indicativo, l'importante è che non appaia la parola vulnerable.
un router deve avere un server ssh/telnet in ascolto per essere vulberabile, giusto?
Occhio a creare panico *immotivato*, come in questo articolo. I dispositivi embedded (router, etc) *non sono* vulnerabili!
Leggendo l'articolo la lista dei modi in cui si può sfruttare 'sta cosa è piuttosto lunga. Ma basta non installare bash.
Toh, si parlava della presunta superiorità dell'open a livello di sicurezza proprio qualche tempo fa. Quando mai si capirà che lo slogan "lo possono verificare e correggere tutti, quindi è sicuro" è al pari di "it just works" di Apple (vedere streming, cellulari da 1000 euro che si piegano, update 8.0.1 che rompe tutto). Sono posizioni DOGMATICHE che non hanno nulla a che vedere con la realtà.

PUNTO UNO: bagno di realtà. Questo bug è fuori da 22 anni. E ce ne sono mille altri come lui, non ancora pubblici. Con questo intendo che in genere questi bug vengono scoperti con largo anticipo e conservati gelosamente o venduti a caro prezzo (notizia dell'altro giorno: http://www.engadget.com/2014/09/24/kevin-mitnick-sells-exploits/) da gruppi di hacker e/o da agenzie governative; quindi resi pubblici quando non servono più, perché ne usi degli altri più efficaci.
PUNTO DUE: open o closed la differenza la fa la qualità del codice. Quello dell'attuale open è estremamente altalenante, è un puzzle di pezzi in cui ci sono poche parti ben curate (perché ci lavorano full time professionisti, tipo il kernel), e altre portate avanti alla buona indipendentemente da quanto siano importanti (vedi OpenSSL, alle quali fino a Hearthbleed ci lavorava UNA persona full e una part time... su un pezzo di software fondamentale per la sicurezza di più della metà dei server mondiali!!!). Per lo meno sul nucleo delle parti più importanti dovrebbero esserci standard qualitativi, controllo qualità, procedure di verifica e certificazione, e invece ogni parte è una storia a se.

Ditemi che è flessibile, che è portabile, che ci si fa di tutto ma per favore non andate più in giro a dire che E' SICURO adducendo i soliti ritornelli scemi che girano a ogni discussione open vs closed. Lo dico avendo in giro qualche decina di server (e qualche sistema embedded) Linux... smettiamola di fare propaganda, la sicurezza non c'entra con l'open. Ma chi è che ha le competenze, il tempo e la voglia di validarti un pezzo di software magari scritto a vacca? Giusto chi ha l'interesse di non dirlo in giro e farci profitto.

La carbonara la si fa bene se la si fa bene, non se si condivide su Facebook la propria ricetta. Se sei un pessimo cuoco lo sei anche se sei open.

Con questo ribadisco: Linux (e i *nix in generale) su una serie di cose ha dei vantaggi indiscussi, non userei mai altro per certi contesti. Non abbiate la pretesa di dire che è meglio SU TUTTO, sulla sicurezza finché si paragonava ai Windows groviera di un tempo era sicuramente avanti. Oggi lo scenario è cambiato, ma Linux non è riuscito ancora a cambiare passo, è ancora fatto da mille smanettoni con mille teste diverse (a parte ripeto kernel e poco altro).
Per quanto mi riguarda Debian 7 mi risulta esente dal problema

luca@debian:~/running$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
pare che la patch non serva a molto https://twitter.com/taviso/status/514887394294652929
Riccardo, un po' troppi sistemi implementano le UI di gestione via browser tramite CGI, che utilizza variabili d'ambiente per passare i parametri dalla richiesta HTTP al software. In questo caso puoi far eseguire al server web un qualsiasi comando passando la "giusta" variabile. Inoltre la chiamata system per eseguire comandi arbitrari utilizza la shell, quindi anche se il server Web non esegue una shell per chiamare la web app, una qualsiasi web app rischia di eseguire comandi arbitrari successivamente.

Come ha fatto già notare Luca Sommacal, per fortuna la maggior parte di router/tv/etc. usa BusyBox come shell e non Bash. E i server Debian/Ubuntu non sono affetti (anche se non hanno bash aggiornata) perché la shell utilizzata di default per le sessioni non-interattive è Dash. Per i sistemi FreeBSD il problema si risolve ancora prima: non utilizzano bash di default proprio. Nel caso di OSX il problema è simile a Debian/Ubuntu: sì le sessioni utente interattive usano bash, ma le chiamate a system() usano un'altra shell, quindi non sono vulnerabili al problema più grosso.

Molto più a rischio sono i server che espongono/esponevano comandi via ssh con autenticazione nota basandosi sulla limitazione dei comandi autorizzati, che viene completamente scavalcata.
Confermo la vulnerabilità anche su OSX Yosemite Beta 3
Timothy,

Occhio a creare panico *immotivato*, come in questo articolo. I dispositivi embedded (router, etc) *non sono* vulnerabili!

E' il NIST, non io, a classificarlo come bug di categoria 10.

Sei disposto a garantire per tutti i dispositivi embedded? Anche per il frigorifero "smart" o il sensore di fumo della rete di domotica? :-)

Io sarei più cauto prima di dichiarare l'invulnerabilità, sempre e comunque.
Per chi lo chiedeva: per verificare se il proprio router è vulnerabile bisogna potersi collegare ad esso tramite telnet o SSH, molti router hanno l'opzione per abilitare l'accesso tramite ssh. E comunque molti router utilizzano busybox. Controllate nel log del vostro router se salta fuori la parola busybox :)
>Improvvisamente l'Internet delle Cose non sembra più una bell'idea come prima.

Quando mai lo è stata?
Ho perso un'ora a tentare di capire la gravità e posso dire, in base alla mia esperienza, che si tratta per lo più di panico immotivato. Il problema è solo in chi usa bash o nei programmi che hanno la possibilità di lanciare script bash (come Apache, per fare l'esempio più clamoroso).
Il problema è, quindi, forte solo se tali programmi girano con privilegi elevati, cosa che di solito non avviene.
Grazie al fatto che questo è un SW open possiamo facilmente risalire alla data del bug, al diff incriminato e all'autore dell'errore, apprendendo qualcosa di nuovo; in più un programmatore esperto sarebbe stato in grado di produrre la patch facilmente.
Ovviamente mi aspetto presto un commento da qualcuno (tipo Fx) che dirà che questo dimostra che l'open non funziona, che il bug era in giro da decenni... ma penso non valga nemmeno la pena spiegare dov'è l'errore.
Beh in un server serio la chiamata system() è disabilitata di default. In più bisognerebbe "sanitizzare" gli input proprio per evitare che vengano eseguite "schifezze".

Sui privilegi, non sono abbastanza esperto per capire se posso tirare su una shell con privilegi elevati, ma basta poter scrivere in /etc e il danno è fatto.. Insomma se cerco di eseguire "su root" secondo me *nix un attimino si incazza...
Questa falla ha dell'incredibile. Come sia possibile che sia sfuggita per 20 anni resta per me il mistero maggiore.

Noto inoltre che la soluzione fornita nel link dell'articolo per OS X ("Se comunque non vi va di attendere che Apple turi la falla, ci sono delle soluzioni qui.") non sembra proteggere realmente il computer.

Inoltre, aggiungerei all'articolo di stare molto attenti nel seguire le istruzioni a "System Binaries". Nell'articolo originale viene suggerito di fare un backup prima di fare questi cambiamenti:

You are advised to take backups before you make these changes and test that you can log in before you quit the shell you have started (because if there are problems you may not be able to fix this afterwards). When Apple release a fix you are recommended to apply that and verify that the new Apple version is used instead.

...altrimenti si rischia il disastro. Questo avviso non era esplicito nell'articolo su stackexchange, cosa che genera, in caso di ricompilazione un po' frettolosa, grossi problemi, come accaduto a me :(
personalmente trovo l'internet delle cose uno strumento che come sempre può portare grandi benefici e grandi disastri. Come tutte le... cose, tutto dipende dall uso che se ne fa.

Ricorderò sempre un articolo di Martin Gardner su Le Scienze di xxxanta anni fa (anni '60?), dove in una specie di racconto si raccontava di un geniale inventore che propone a degli investitori un'invenzione prodigiosa, in grado di rivoluzionare letteralmente il mondo.

Dopo la presentazione il panel di investitori è entusiasta dell'idea ma, come sempre, deciso ad andarci con i piedi di piombo. Così chiedono al geniale inventore di dare conto non solo dei benefici ma anche di eventuali lati negativi. Al che questi risponde "ma, niente di che, giusto un mezzo milione di morti all'anno...".

Quell'invenzione era naturalmente l'automobile.
Grazie Paolo!

Ho immediatamente aggiornato i server debian che gestisco, e il responso dello script di test è passato da "vulnerabile" a "non vulnerabile" nel giro di un dist-upgrade :-P
Certe volte ci si dimentica dei buoni vecchi "permessi negati"...

$ env x='() { :;}; touch /ciao' bash -c "echo prova"
touch: impossibile fare touch di "/ciao": Permesso negato
Errore di segmentazione (core dumped)

[andre@pc-andre ~]$ env x='() { :;}; sudo touch /ciao' bash -c "echo prova"
Password:
Riprovare.
Password:
Riprovare.
Password:
Riprovare.
sudo: 3 tentativi di immissione password non corretti
Errore di segmentazione (core dumped)

Forse casco dalle nuvole, ma non capisco che senso abbia la vulnerabilità se poi non bypassa i permessi di root, ma esegue solo codice normalmente eseguibile senza sudo. :-?
Il test sul mio debian wheezy risulta negativo. Guardando il changelog delle modifiche al pacchetto bash di debian risulta che il problema e' stato corretto il 19 settembre 2014: come mai la notizia e' esplosa solo 6 giorni dopo?
Cpaolo: si ok quindi il vantaggio dell'open è che sappiamo il volontario che ha sbagliato 22 anni fa, mentre nel closed non usano il versioning e sono tutti incappucciati, perché per sviluppare closed devi essere un ninja.
E il bug non è così grave, d'altronde il bash lo usano servizi di importanza modesta come per l'appunto Apache... È a rischio solo il 60% dei webserver mondiali, poteva andare peggio... Poteva piovere
@Scatola
Paolo, sebbene Linux e la famiglia Unix abbiano lo stesso aspetto e comportamento non sono esattamente la stessa cosa. Inoltre Linux sarebbe il solo kernel mentre il resto dei programmi accessori si chiama GNU, e il sistema operativo GNU/Linux, che sarebbe l'acronimo di GNU's Not Unix

[l'angolo del nostalgicone]
Ah, i bei tempi del forum "Internet per tutti", quando i nerd erano veri nerd, i complottisti praticamente non c'erano e il massimo dei flame erano "Windows vs Linux" o peggio "Linux vs GNU/Linux"! :D
[/l'angolo del nostalgicone]

@martinobri
Improvvisamente l'Internet delle Cose non sembra più una bell'idea come prima.

Quando mai lo è stata?


Come buzzword funziona benissimo, i miei capi, capetti e supercapocciamondiali non fanno che ripeterla senza aver probabilmente capito davvero cosa sia. Così come "big data", "software as a service" e gli evergreen sempre di moda come "paradigm shift".
http://gigwalkblog.com/wp-content/uploads/2014/03/Big-Data-Meme.jpg
Nel giro di poche ore un secondo dist-upgrade porta il pacchetto bash da -u1 a -u3, presumo per incorporare la "patch della patch" di cui si parla negli articoli menzionati.
Per rispondere a qualcuno...Open è più sicuro di close?
che garanzie promette il closed source IN PIU' rispetto all'open source che una falla, una volta scoperta, venga riparata?
Io, con Ubuntu, non mi sono nemmeno accorto del problema perché mentre leggevo questo blog il sistema si è aggiornato e ha corretto la falla DA SOLO.
Stiamo ai fatti: falla scoperta, falla riparata.
Piccola precisazione, Mac e Linux non sono sistemi basati su Unix, Linux é solo il kernel ed il sistema operativo non é Unix, mentre Mac si basa su Darwin, versione avanzata del BSD, nato come alternativa a Unix. Correttamente bisognerebbe parlare di sistemi 'Unix-like', anche perché di Unix veri e propri sono rimani solo AIX di IBM, Solaris ed una versione cinese fatta per il mercato interno cinese.

Detto questo... l'articolo genera panico immotivato, anche perché negli articoli citati ci sono un paio di cose da tenere in considerazione:

"We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice." - RedHat

Giá solo questa lascia intendere che il bug é sfruttabile via remoto se ci sono delle cattivi implementazioni, ovviamente non il 100% dei sistemi é ben sviluppato, quindi la vulnerabilità é certamente da non sottovalutare, ma asserire che sia l'apocalisse informatica é probabilmente esagerato.

Altra cosa importante, direttamente da Rapid7, i ragazzi che curano Metasploit, il tool più usato al mondo per i PenTest:
"The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue."
https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271

Per terminare correggo l'ultimo commento fatto su Apache... Apache non usa bash, o meglio, il software senza estensioni usa bash solo per i piped logs (la falla si chiude usando || invece che | per le directory dei logs) ed alcune piccole cose come le chiamate popen() o system(), funzioni che raramente si usano ancora direttamente (CPanel pare ne faccia ancora uso per alcuni tool interni datati, per esempio). Oltre a questo, Apache diventa facilmente attaccabile se il mod_cgi é attivo ed utilizzato, ora, questa pratica é ormai deprecata da anni perché ritenuta profondamente rischiosa, ci sono strade alternative come FastCGI che utilizza i file descriptors' per le variabili d'ambiente, quindi la falla non é sfruttabile. Ultima cosa, c'é da ricordare che questo bug non permette la scalata dei privilegi, quindi per fare danni ci vorrebbe un attacco per recuperare user/pass del database usato dal software installato e sperare che quei dati corrispondano ad un account sulla macchina o che la password sia la stessa di root, cioé una concatenazione di cattive pratiche che purtroppo é ancora comune.

L'unico utilizzo veramente importante é il server DHCP modificato, ma qui c'é sempre la volontà dell'utente nell'entrare in una rete sconosciuta, perché in quella di casa i malintenzionati non possono entrare sfruttando questa falla visto che il buon 90% dei router casalinghi usa altro, per esempio BusyBox ("A quick review of a approximately 50 firmware images from a variety of enterprise, industrial, and consumer devices turned up no instances where Bash was included in the filesystem." Rapid7).

Quindi, piuttosto che generare panico immotivato, magari sarebbe ora di prendere la palla al balzo per rimarcare che l'insicurezza dei sistemi é quasi sempre dovuta alla componente umana, non tecnica: password simili, cattive implementazioni software, cattive installazioni, ecc...

Forse Heartbleed era dannatamente più pericoloso, al netto, perché spacciarsi per qualcun altro, usando un certificato che ne conferma l'identità é ben altra cosa... ma poi queste sono opinioni.
Forse il livello 10 di pericolosità della falla è stato assegnato per la relativa semplicità di sfruttamento.
Persino io, che non sono certo un sistemista (mi ritengo un utente un po' più avanzato, infatti ero tra quelli che sapevano spegnere Windows '95(*) :-) ), potrei riuscire a sfruttarla anche se in condizioni più particolari (per esempio, accedere fisicamente al pc linux/unix/mac con bash aperto e conoscendo la password di root :-D )

(*) Non vi sembri troppo strano. Quando apparvero i primi computer con Windows 95, chi non comprava riviste di informatica e non aveva accesso ad internet (erano la maggioranza), non eseguivano l'arresto di Windows, ma, semplicemente, spegnevano il computer dopo aver salvato il loro lavoro; esattamente come si faceva col DOS.
La rivisitazione dell'articolo adesso rende molto bene l'idea con cosa si ha a che fare!
Come sempre ottimo lavoro Paolo!
#FX discorso che potrebbe essere esatto, ma purtroppo ti autodistruggi sul Punto 2.
Chi ti dice che invece il cloused è elegante, perfetto, ben fatto, ecc. ecc come affermi? proprio perché cloused la risposta esatta sarebbe invece "non sappiamo come è scritto il cloused. Potrebbe essere anche questo uno schifo. Peggiore anche dell'open"
Oggi dello stesso argomento (ma sarà un caso?) se ne occupa una delle maggiori fonti di ignoranza giornalistica che ne parla con la solita, abituale incompetenza ("Shellshock, il VIRUS che minaccia Linux e Apple") oltre che con un improbabilissimo italiano ("Secondo gli esperti per sistemare adeguatamente la falla ci vorranno anni, e quel che è più ciò sarà compito non dei singoli utenti ma dagli amministratori di sistema (SIC!) e dei webmaster visto che ad essere interessanti sono potenzialmente milioni di server in tutto il mondo").
@Fx
Non è la panacea di tutti i mali, ma l'open source continua ad avere i suoi perché nella sicurezza. Come dice Schneier:
"Invariably we're going to see articles pointing at this and at Heartbleed and claim a trend in vulnerabilities in open-source software. If anyone has any actual data other than these two instances and the natural human tendency to generalize, I'd like to see it."

@pgc
È molto facile spiegarsi come mai dei bug esistano per 20 anni. Basta vedere il team di sviluppo della bash shell. Quante persone sono? Per OpenSSL erano 4 gatti a tempo perso. Nessuno si sentiva obbligato a pagare per una roba gratis, fino a quando qualcuno si è svegliato. Scommettiamo che con la bash è successa la stessa cosa? Quanti buchi bisognerà scoprire prima di imparare che gratis (e open) non significa necessariamente tenere il portafoglio chiuso?

@all
Informo che con:

CentOS release 6.5 (Final)

dopo aver installato la patch:

bash x86_64 4.1.2-15.el6_5.2 updates 905 k

Il comportamento del test è questo:

# env x='() { :;}; echo vulnerabile' bash -c "echo prova"
prova

Allora. Non mi sembra difficile. Ve lo ripeto.

Open e closed non hanno alcuna attinenza con la qualità, che ha origine da altre cose (ne ho indicate alcune). Siete voi a indicare l'open come la panacea di tutti i mali, che sia sinonimo di sicurezza; non io a dire che closed significa automaticamente scritto bene. Ecco, l'equazione open = sicurezza è una s. Fine.
ilcomizietto, è esattamente quello che deve succedere: la shell deve ignorare il comando dentro la variabile (il primo echo) ed eseguire solo quello dopo il ; Il fatto che non visualizzi il messaggio d'errore è ininfluente.
@bontoJR
"We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice." - RedHat

Giá solo questa lascia intendere che il bug é sfruttabile via remoto se ci sono delle cattivi implementazioni, ovviamente non il 100% dei sistemi é ben sviluppato, quindi la vulnerabilità é certamente da non sottovalutare, ma asserire che sia l'apocalisse informatica é probabilmente esagerato.


Forse il mio inglese fa schifo, ma io la interpreto in un altro modo: stanno dicendo che una volta applicata la patch, eventuali script esistenti che usavano cattive pratiche di programmazione riguardo alle variabili d'ambiente smetteranno di funzionare. NON stanno dicendo che l'attacco necessita di avere GIA' sul computer-vittima degli script che usano cattive pratiche di programmazione riguardo alle variabili d'ambiente, perché in questo tipo di attacco le variabili d'ambiente opportunamente truccate vengono "fornite" dall'attaccante. O ho capito male?
I complottisti direbbero che :
Nell' open source sono "4 gatti" perchè nessuno fà più nulla
per incentivare la programmazione da parte degli utenti.
Non è più come ai tempi del vecchio ibm-basic, C64, o ms-dos
(TurboC Fortran ecc.ecc.) dove anche un hobbista poteva scriversi
il suo programmino e divertirsi a scoprire il mondo dei microprocessori.
Anzi, oggi tutto il contrario, ora l'utente deve essere un utile idiota,
e allora si incentiva il software chiuso e per quei pochi irriducibili,
la programmazione ad oggetti.
Ovviamente, perchè l'algoritmo mpx33 è di proprietà della ditta pincopalla,
che con i diritti ci guadagna fantastiliardi e vuole continuare a guadagnarci.
*
Comunque tornando a bash, chi ha i privilegi anche solo di utente,
può sempre combinare guai con i comandi della fork bomb.
l'unico rimedio allora è tenere il sistema lontano da intrusioni non autorizzate.
@Fx
Nelle discussioni in cui sono "incappato" io non si diceva che un SO open è oggettivamente più sicuro di uno closed. Si diceva solo che i tempi di risposta per la correzione di una falla di sicurezza, una volta scoperta, sono molto più rapidi nell'open che nel closed.
Questo elemento è fattore di maggior sicurezza rispetto al closed.

Un software (dal sistema operativo al programmino che scrive "Hello World") deve essere robusto in partenza, dal momento in cui si scrive il codice sorgente. Mi sembra ovvio che meno persone ci siano a lavorare sul codice di un software più sia facile che ci siano grossi bug e che il software sia mal progettato. Questo vale indipendentemente dalla natura open o closed del software.

La scoperta di falle avviene sopratturro sul campo.
Secondo me, più un software è diffuso e utilizzato maggiori sono le probabilità che sia robusto perché, sebbene ci siano persone che se scoprono falle non le comunicano per "motivi personali", ce ne sono molte altre che, anche solo per avere visibilità, le comunicano subito.

Concludendo,
un software molto diffuso è più testato e, quindi, statisticamente più sicuro;
un software open molto diffuso è ancora più sicuro (sempre statisticamente) perché ci sono i sorgenti che permettono di scovare bug più rapidamente (questo è oggettivo, il fatto che nessuno guardi i sorgenti non c'entra col fatto che il codice sorgente agevoli il lavoro di scoperta e correzione di bug) che e perché i tempi per la correzione di eventuali falle sono mediamente più rapidi.

Le falle di bash ed SSH rientrano tranquillamente in questo discorso: bash ed SSH, infatti, non sono gli unici software open utilizzati al mondo, e due falle, seppur grosse, non cambiano di molto le cose dal punto di vista statistico.

Lo stesso vale per il closed. Chi dice, ad esempio, che Windows non è sicuro sbaglia.
Windows è molto diffuso ed è robusto: molte sue falle sono state scoperte e turate
I virus di cui molti si lamentano di prendere "senza aver fatto nulla" ("ho solo cliccato su un video di Belen, non ho installato nulla. Un video non può essere un virus Nooo? E' sto schifo di Windows che si infetta da solo!!!") partono da azioni dell'utente.
Se i MacOS avessero la stessa diffusione di Windows ci sarebbero gli stessi problemi di Windows.

I sistemi Mac OS sono meno diffusi e questo, secondo me, aumenta le probabilità che ci siano falle gravi sconosciute. A suo favore gioca il fatto che sia un sistema unix like. Così, se si scopre una falla per *nix come quella di bash, ecco che quella è anche una falla di Mac OS e, indirettamente, anche il Mac OS diventa più solido. Però la falla è stata già chiusa per chi usa sistemi open, mentre Apple sembra che non l'abbia ancora fatto.
@Fx
Forse è solo una precisazione futile, ma anche la tua affermazione non è corretta. Tu affermi che l'open source non assicura nulla in fatto di sicurezza. Non c'è garanzia di nulla e un buon software può essere open o closed, ma è anche vero che è più probabile che un problema venga rilevato su un software open o su un software closed? Sicuramente il primo, perché il sorgente è aperto. Inoltre, e qui è stato dimostrato, se c'è un bug viene corretto in tempi celeri. Parliamo di Microsoft che non tappò la falla sui file WMF provocando una vera ondata di sistemi infetti?

E non ha nemmeno senso parlare di bug di "20 anni fa", perché ad oggi vengono scoperti bug in windows che riguardano pezzi di codice che sono lì da quando esiste DOS, ormai di anni ne son passati ben di più.
La domanda da porsi è: "per mantenere interoperabilità e manutenzione è meglio un software closed o open?"
Risposta: open, il closed da un giorno all'altro può fare *PUFF*
D'altro canto, gli standard attuali sono, per definizione, pubblici.

Dovrebbe far riflettere, invece, che molti colossi dell'informatica usano librerie, software e altro con licenza libera senza versare un soldo a chi li gestisce con ovvi risultati. Se fossero da riconoscere delle royality a OpenSSH e simili, quanti MILIARDI spetterebbero a loro? Ecco. Allora, se questi colossi dell'informatica destinassero un centinaio di migliaia di dollari (che per loro sono un nulla) ad aiutare queste persone ne guadagnerebbero loro innanzitutto.
@Willy
Ubuntu 12.04 LTS

Confermo anche dal mio buon vecchio catorcione che ha Xubuntu 12.04, la patch è un'occasione per rispolverarlo :)
A proposito del mio vecchio catorcio. Con gli aggiornamenti automagici è andato tutto bene, ma pensavo, LTS significa tre anni di supporto, e dall'aprile 2012 non sono ancora passati: se il problema fosse stato scoperto dopo i fatidici tre anni, sarebbero usciti ugualmente aggiornamenti per Xubuntu 12.04 ? O avrei dovuto passare a, poniamo, Xubuntu 14 ? (che magari non gira, come non girava Xubuntu 13, se ricordo bene aveva problemi perché alla mia CPU troppo vecchia mancavano certe funzioni "modeeeeerne"). O ci sarebbe stata la possibilità di aggiornare solo Bash? O sarebbe stato necessario cercare una distro che fosse sia compatibile con una vecchia CPU sia aggiornabile alla versione patchata? Scusate per la domanda stupida, purtroppo sull'argomento pinguino sono fermo a ... "Da Windows a Linux" del nostro Paolo, libro del lontano 1999! :)

p.s. Riguardo all'Internet delle Cose, mi è piaciuta l'ultima faq di Red Hat: "E' vero che anche le mie lampadine potrebbero essere colpite dal problema?" - "Solo se le tue lampadine usano Bash!". Da qui si distingue il vero nerd, le sue lampadine sono a riga di comando, quelle degli altri hanno le icone!
ilcomizietto: È molto facile spiegarsi come mai dei bug esistano per 20 anni. Basta vedere il team di sviluppo della bash shell. .

Non sono d'accordo. La scoperta di bug dipende non solo dal numero di sviluppatori ma anche dal numero di utenti, che per bash forse si misura in triliardi di linee di comando . Quello che mi ha lasciato di stucco è la semplicità del bug. Nulla di capzioso e incomprensibile ai più, ma una cosa riconoscibile da chiunque abbia un minimo di esperienza di CLI in Unix.

E nel frattempo i Mac continuano a risultare in parte scoperti. Non che mi preoccupi più di tanto (in realtà sembra che l'accesso al bug non sia così banale) ma insomma. I consigli dati non si applicano facilmente ad alcune macchine.
@pgc
Beh, openSSH gli utilizzatori sono tutti quelli che non usano software by Redmond. Comunque è impressionante come due bug in software Open facciano notizia, mentre certi sfaceli di Microsoft passino sotto silenzio. Così si rischia solo di fare il gioco di una multinazionale.
Guastulfo, Lufo: io non spenderei la parola "oggettivo" senza che ci sia un'analisi scientifica che conferma certe tesi.

Inoltre mi incentrate la questione sicurezza sulla velocità di turare le falle, e che con l'open, vedendo il codice, puoi individuare più velocemente i bug.

Contesto parzialmente o integralmente tutte e due le affermazioni.

La prima: il punto non è la velocità di correzione dei bug, che non ha molto senso (si, quando diventa mainstream devi esser rapido, ma in quei casi sono tutti rapidi, altrimenti se è aperto da anni una settimana avanti indietro cambia poco), ma l'affidabilità della patch. Torno alla questione procedure, controllo qualità eccetera. Non a caso le patch per questo bug sembrano risolvere un problema e aprirne un altro, proprio perché non si agisce con standard di qualità ma in preda all'isteria e con poca professionalità.
Inoltre per me il punto è minimizzare i bug prima ancora che preoccuparsi di correggerli velocemente una volta scoperti. Una volta scoperti è comunque tardi. Meglio cercare di limitarne il numero. E come lo fai? Procedure, controlli, standard di qualità, eccetera.

Seconda cosa: i bug li scopri con l'uso. Con l'open puoi verificare la causa, che paradossalmente è un vantaggio clamoroso per chi vuole sfruttare la falla; per correggerla poco (se è closed segnali il bug e poi ci penserà chi di dovere a guardare la causa e correggerla).

Ripeto nuovamente: l'open ha grossi vantaggi. La sicurezza non la includerei tra questi. Per lo meno finché non ne verrà standardizzato lo sviluppo.
@lufo
Comunque è impressionante come due bug in software Open facciano notizia, mentre certi sfaceli di Microsoft passino sotto silenzio

Impressionante? No, solo umano. Al secchione della classe quelle due insufficienze non si perdonano. Se Attivissimo fa un errore, stracciamento di vesti, se lo fa Repubblica... sollevamento di spalle.
Gli sfaceli di Microsoft li abbiamo davanti ogni secondo martedì del mese, da anni: è come un odore fastidioso in una stanza, non ci facciamo più caso (centrale in Iran bucata? "colpa di chi non aveva installato le patch", non "colpa di Microsoft che fa sistemi colabrodo"...).
@Diego Elio Pettenò
Potresti darmi una url che possa permettermi di crashare i miei device con web/cgi come UI?
Il test mi sembra poco utile di per sè.
@fx
se con l'open puoi verificarne la causa è anche vero che uno sviluppatore terzo può scoprire la falla e presentare subito la correzione o indicare le linee di codice che presentano il problema.. Quanto tempo risparmia l'azienda o il gruppo di persone che devono corregge il bug? Come vedi lo svantaggio di cui parli non c'è.
"Non a caso le patch per questo bug sembrano risolvere un problema e aprirne un altro, proprio perché non si agisce con standard di qualità ma in preda all'isteria e con poca professionalità."
Come succede con Microsoft, come è appena successo con l'aggiornamento 8.0.1 di iOS. Apple e Microsoft sono poco professionali? La tua accusa va estesa a praticamente l'intero mondo software. Quindi c'è qualcosa che non va nel tuo pensiero se ti riferisci implicitamente all'open.

"Inoltre per me il punto è minimizzare i bug prima ancora che preoccuparsi di correggerli velocemente una volta scoperti. Una volta scoperti è comunque tardi. Meglio cercare di limitarne il numero. E come lo fai? Procedure, controlli, standard di qualità, eccetera. "
Scusa, parli di professionalità...come fai a dimostrare che non c'è stata da parte di chi ha sviluppato questi software? Se la risposta è "non ci sarebbero questi bug" allora non conosci uno dei principi base dell'ingegneria del software, ovvero l'impossibilità di dimostrare l'assenza di bug. E se ci sono voluti 20 anni per scoprirlo, tanto ovvio non era. Non credi?
E ripeto, Microsoft e Apple? O netgear che ha venduto migliaia di router con un'implementazione errata dello standard 802.11? Li fanno i loro macelli, come li fa Oracle, come li fanno tutte le multinazionali del settore.
Allora, come puoi constatare, closed non implica nessun vantaggio certo.

Il discorso della sicurezza e dell'open, non è tanto garantire che un software open funzioni MEGLIO di un closed sotto questo aspetto, ma ha un'arma in più che il closed non ha: la possibilità che un numero elevato di persone revisioni il codice scritto. Questo per software che devono interagire tra loro è fondamentale. In ambito sicurezza il numero di test e revisioni è un aspetto ancora più fondamentale dei normali software. Non garantisce nulla, ma è comunque un punto a favore che con il closed non ha.
Ripeto: per me è un punto a sfavore. Il bug lo rilevi sul funzionamento del software, non leggendo il codice (a meno tu non sia Neo di Matrix), quindi open / closed si equivalgono. Poi cosa succede? In un mondo ideale viene fatto un bug report. Nel nostro mondo invece ci sono TANTE persone che hanno interesse a non fare il report ma a sfruttare la loro scoperta. E qui l'open stende loro un tappeto rosso, dando la possibilità di vedere dov'è il bug lato sorgente e quindi di studiare in modo estremamente più facile come sfruttare al meglio il bug. Con il closed devi fare ingegneria inversa sul codice macchina, e hai una serie di complicazioni notevoli.

Inoltre lo scenario REALE vede che tutto questo appassionamento al bug hunting sull'open non c'è, vedi gli ultimi bug clamorosi che sono usciti. Probabilmente gli sviluppatori esternu si concentrano su progetti meno pallosi di OpenSSL e Bash, dopotutti già è volontariato, perché poi mi dovrei sparare sulle palle con cose così noiose?

Per quanto riguarda le patch che introducono altri bug: guarda che a Microsoft e a Apple succede ma estremamente raramente. L'esempio di iOS 8.0.1 è completamente fuori strada, stai facendo paragoni mele con pere. Io parlavo del caso in cui la singola patch al singolo bug introduce un altro bug o non lo corregge completamente (ripeto: il bug della shell è stato corretto velocemente - dopo che è diventato mainstream, chissà da quanto lo sfruttavano - ma... non è stato corretto bene), mentre tu mi parli del caso in cui un aggiornamento di tutto l'os che introduce n nuove funzionalità. Al di là del fatto che non prenderei Apple come riferimento perché non è una software house e non è manco capace di scriversi un os da sola (lo faceva e poi è passata a Darwin).

Per quanto riguarda Microsoft credo siate fermi a una decina di anni fa... Esistono servizi dove elencano i bug per gravità, se sono aperti o meno, e soprattutto per piattaforma. Fateci. Un giro. E al di là di questo esiste codice leaked di alcuni (vecchi) os di MS come Windows 2000, io gli darei un'occhiata e poi darei un'occhiata a Linux...

Poi parlerei. Si chiama cognizione si causa.
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/

Se per voi il pregio di Linux è la sicurezza, non oso pensare ai difetti =) questa è la cosa che più odio degli evangelisti, dei fanboy o dei semplici tifosi: ciò per cui parteggiano dev'essere meglio su tutto. È stupido perché è palesemente irrealistico che l'altro abbia solo difetti e il proprio solo pregi. Sembra di leggere Libero o il Giornale.

Forse vi siete persi che al di là dell'uso desktop uso solo Linux (n server, computer embedded, eccetera)... Ovvero 20 macchine Linux per una Windows.
Beh l'open non può sparire da un giorno all' altro... Truecrypt? Si stufa il principale mantainer, toh non si aggiorna più.. Fatevi un giro su sourceforge per vedere quanti progetti muoiono ;-)
@Fx
Mi sa che del mio commento hai letto solo il primo rigo, E PURE MALE :-)
Non ho mai usato la parola "oggettivo" come l'hai intesa tu.

Io dico sostanzialmente quello che dici tu, le differenze stanno su cosa basiamo le nostre valutazioni.
Tu affermi che il fatto che un codice nascosto sia un vantaggio per la sicurezza, io ti dico che non è mai stato vero. E' del tutto ininfluente che un codice sia noto o meno. L'unica prova valida di affidabilità la dà il campo.

Pensi che sia un'affermazione forte? Vediamo. Lessi su un libro (vorrei ricordarmi quale, credo che fosse di storia della matematica) che un tempo si pensava che i codici di cifratura in cui si nascondeva l'algoritmo erano più robusti. Poi si scoprì che non era così: conosciamo perfettamente come funzionano i codici di cifratura più forti, eppure nonostante gli algoritmi siano "open" tali metodi restano forti. E' il "campo" che ha dimostrato la loro validità. Sono la migliore prova che nascondere "come fai" non ti rende più forte.

Per esempio Enigma, la macchina per la cifratura dei messaggi tedesca, fu violata prima ancora che un suo esemplare entrasse in possesso degli inglesi, eppure era "closed".

Riguardo ai sistemi operativi, io ho affermato in quel commento che Windows si è "irrobustito" sul campo. esattamente come i sistemi *nix, visto che su molti server (forse la maggior parte di quelli che forniscono servizi tipo mail server, web server e DNS) girano sistemi open.

Le aziende che li usano, immagino, si sappiano fare i conti. Se il risparmio sulle licenze avesse come rovescio della medaglia danni provenienti da continui attacchi derivanti da falle aperte, queste aziende avrebbero già migrato i loro sistemi verso soluzioni closed: i loro dati valgono sicuramente di più dell'acquisto di qualche licenza.

Ho anche detto che la sicurezza di MacOS è riflesso dei sistemi open, bash ne è la dimostrazione. Ma i sistemi Mac non godono della stessa diffusione di quelli Windows e Linux, per questo non li ritengo altrettanto sicuri.

Non sono in grado di leggere il codice sorgente di un sistema operastivo. Una volta quardai quello relativo al kernet di un a distro Linux. Hanno una complessità mostruosa. Non so se una lettura del sorgente permette davvero una precisa valutazione della validità del progetto complessivo.

Quindi, mi spieghi dove sarei un fanboy?
Io, invece, ho l'impressione che il tuo sia un comportamento da "hateboy" nei confronti dei sistemi open, perché tu dici che closed è più sicuro perché non hai i sorgenti che aiutano a scovare i bug e io dico che l'avere i sorgenti in mano non cambia di una virlgola le cose per la sicurezza: la robustezza di un sistema la dimostra il campo. I sistemi open sono molto usati anche in posti delicati e penso che chi li usa abbia fatto le sue valutazioni. Se fosse come dici tu, da un pezzo avremmo in giro solo sistemi closed.

O, forse, pensi che tu sia l'unico ad essersi reso reso conto che open = insicuro e closed = sicuro?

Si fa per parlà eh? :-
@Fx: chiedo scusa, mi ero ripromesso di non risponderti, ma hai condensato una lunga serie di castronerie in poche righe. Non so da dove cominciare: leggi questo http://www.oversecurity.net/2014/09/29/tutto-devi-sapere-shellshock/
Poi studia un paio di anni e ritorno a commentare; altrimenti meglio evitare di fare discorsi da bar Sport.
Scusa ma quell'articolo non dice niente di più di quando c'è scritto poco sopra.
Se non c'è un webserver attivo come fai a sfruttare la falla? SSH non mi pare esegua bash prima del login. I server web che usano CGI solitamente hanno accesso in rw alla dir dei file temporanei, ma di solito la temp è montata come noexec, quindi http://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec come dicono qua, non posso eseguirci binari).

Ma soprattutto se il problema è in bash, se uso un'altra shell dovrei essere a posto.
@Fx
"vedi gli ultimi bug clamorosi che sono usciti"
Affermazione priva di senso. Ne sono usciti due di clamorosi, in due software diversi. Per giunta questo qui è sì clamoroso, ma allo stesso tempo i danni sono molto limitati se i server sono fatti come dio comanda. Quanti bug altrettanto devastanti ci sono stati in sistemi closed?
E come già detto dire che c'è un bug e quindi non sono professionali vuol dire non conoscere l'assioma che l'assenza di bug è indimostrabile.

"In un mondo ideale viene fatto un bug report. Nel nostro mondo invece ci sono TANTE persone che hanno interesse a non fare il report ma a sfruttare la loro scoperta. E qui l'open stende loro un tappeto rosso, dando la possibilità di vedere dov'è il bug lato sorgente e quindi di studiare in modo estremamente più facile come sfruttare al meglio il bug. Con il closed devi fare ingegneria inversa sul codice macchina, e hai una serie di complicazioni notevoli."
Come ci sono le persone che non hanno interesse nel fare un bug report per un software open, altrettante per l'ambiente closed.

"Inoltre lo scenario REALE vede che tutto questo appassionamento al bug hunting sull'open non c'è,"
Convinto? Prova a girare nei ticket per i bug di Android, ci sono un sacco di persone che scrivono anche dov'è il problema, altri si spingono a mostrare una correzione, altri fanno direttamente un commit. Come vedi gente che partecipa c'è. Non è tutto rose e fiori, certi progetti come truecrypt sono morti e altri vanno a rilento. Indubbio che lavorare gratis non si può, ma gratis != open.

"L'esempio di iOS 8.0.1 è completamente fuori strada, stai facendo paragoni mele con pere. [...] mentre tu mi parli del caso in cui un aggiornamento di tutto l'os che introduce n nuove funzionalità"
Guardati le release note della 8.0.1 e della 8.0.2. Se non sono patch correttive quelle......
Senza contare tutte le magagne che di tanto in tanto compaiono con gli aggiornamenti di Microsoft (di recente ne ha ritirato uno, mi pare un 3 mesi fa), aggiornamenti nati per correggere problemi, non per aggiungere funzionalità. Non coinvolgono l'intero sistema operativo, ma solo alcune librerie.
Non nascono per portare nuove funzionalità, nascono per correggere problemi esistenti e noti, nascono appunto per correggere un bug esistente e nel caso della 8.0.1 ne ha introdotto un altro. Esattamente lo stesso caso. La differenza è un software contro un intero OS, ma si parlava di patch correttive, no?

"Poi parlerei. Si chiama cognizione si causa."
Eh, ma direi che non sono io, se permetti, a parlare senza cognizione di causa, perché affermare che "non c'è", quando c'è e "fuori strada" quando è evidente che tanto fuori strada non è.....

Ti dirò di più, stai anche confondendo il sistema di ticket e bug report con il concetto di closed/open, quando un buon sistema di ticket esula completamente da questa scelta di sviluppo.

"questa è la cosa che più odio degli evangelisti, dei fanboy o dei semplici tifosi: ciò per cui parteggiano dev'essere meglio su tutto. "
Tira fuori una frase scritta nella discussione dove uno dice che il closed è M****. Ti si sta solo facendo presente che nascondere COME si fanno le cose è controproducente, ma se non credi a noi leggiti gli svariati libri scritti sul concetto di "security through obscurity"

Sulla patch che si è rivelata fallata: sai com'è, certi bug vanno corretti all'istante e in velocità. Lasciare la falla aperta è potenzialmente più dannoso di rilasciare un bug-fix non perfetto. E quanto tempo ci è voluto per avere la patch della patch?
Potrei rispondervi riscrivendo quanto ho già scritto, quindi evito di sprecare cicli con loop infiniti e mi fermo qui.

Io ovviamente rimango convinto, peraltro avendo programmato un po' di anni in assembler x86 e conoscendo le problematiche dell'ingegneria inversa, che capire dal codice macchina come sfruttare un bug nel quale sei incappato o capirlo dal codice sorgente ha due gradi di complessità completamente diversi. A me sembra talmente palese che manco ci sia bisogno di discuterne. Così come degli elevati standard di produzione siano fondamentali sia per mitigare sia il rischio bug sia i potenziali danni di quelli che ti sfuggono.

Ovviamente anche nel closed studiano i bug. La questione in genere è economica. Un gruppo di hacker / una società di sicurezza / un ente governativo magari decide di investire ingenti risorse per studiare bug che riguardano Windows perché sanno che il bug giusto a) può dare loro accesso a centinaia di milioni di PC b) il loro obiettivo magari sono i client e non i server.

Il tutto va ricondotto alle ore uomo. Quante ore uomo (poi potremmo anche entrare in merito sulla soglia di competenza necessaria) servono per scoprire come un buffer overflow può essere sfruttato a proprio vantaggio su un sistema di cui hai il codice e su un sistema di cui non l'hai? Per voi è "pari"?

Non a caso Microsoft e Google riconoscono bei soldoni a chi scopre bug nel loro software. Sanno che una parte di chi indaga un bug lo fa per poi rivenderlo / sfruttarlo, in ultima analisi per guadagnarci.

Note:
1) Guastulfo: il binomio closed = sicuro, open = insicuro non l'ho mai proposto, mi sembra che è n post che propongo l'equivalenza "codice scritto da professionisti con alti standard di qualità, verifiche, procedure, eccetera = tendente a sicuro", auspicando per l'appunto che prima o poi anche il mondo open si svegli e inizi ad adottare degli standard di sviluppo (pretende degli standard di qualità Wikipedia, per un software dovrebbe essere tutto molto più rigido).
Per quanto riguarda hateboy, si, odio chi nega l'evidenza =) Linux invece lo adoro per una serie di motivi tra cui da come avrete capito non metto la sicurezza, proprio perché non ho la pretesa che faccia bene tutto e su tutti i fronti. Come chi pretende di fargli sostituire Windows. Si, puoi usarlo, inefficacemente ma puoi usarlo: se non noti la differenza, è perché ti accontenti di poco te, ma se hai bisogno di essere efficiente Windows Office Photoshop non possono essere sostituiti da Gnome/KDE/Unity/eccetera OpenOffice/LibreOffice/eccetera GIMP. Linux va meglio su alcune cose, Windows va meglio su altre, Os X ha preso il peggio di entrambi i fronti però fa sentire figo chi lo usa e quindi dobbiamo sorbirci anche questi che diventano degli espertoni informatici perché hanno preso un Mac. =)
2) CPaolo79: gne gne. "Studia un paio d'anni" è la classica frase da laureatello che perché ha letto quattro libri e dato due esami pensa di saperne di più di chi smanetta da 20 anni...
3) Lufo: troppo lungo, che sia controproducente significa dire "closed = insicuro", cosa che neghi tu stesso che sia stata detta, quindi c'è un problema di fondo...

Poi ripeto il punto non è che l'open non possa essere sicuro: se segue certi standard che sia open che sia closed offre certe garanzie. IL PUNTO E' CHE NON SEGUE CERTI STANDARD.
@Fx
il binomio closed = sicuro, open = insicuro non l'ho mai proposto, mi sembra che è n post che propongo l'equivalenza "codice scritto da professionisti con alti standard di qualità, verifiche, procedure, eccetera = tendente a sicuro

Ah lo dico anch'io, precisamente l'ho detto quando dicevo che un software deve essere robusto in partenza = scritto bene.
Riguardo agli standard di qualità del closed, anche qui, è tutto da vedere. Non conosco gli standard di qualità dei software closed ma, dove lavoro io, "girano" tanti programmi. A giudicare dalle varie patch di sicurezza, forse, anche il closed ha problemi di qualità.
Inoltre, ripeto, le molte aziende che utilizzano sistemi open non credo siano guidate da idioti incompetenti, non tutte almeno. Se li adottano vuol dire che qualche validità ce l'hanno. Questa è un'evidenza che tu neghi :-)

Il tutto va ricondotto alle ore uomo. Quante ore uomo (poi potremmo anche entrare in merito sulla soglia di competenza necessaria) servono per scoprire come un buffer overflow può essere sfruttato a proprio vantaggio su un sistema di cui hai il codice e su un sistema di cui non l'hai? Per voi è "pari"?

Dalle mie fonti, anche se alcune datate, non è che un hacker si metta a fare necessariamente il reverse engineering. Quello lo si usa per aggirare le attivazioni dei programmi, da Autocad a Photoshop passando per Office e Windows. Quindi se un software (non necessariamente un sistema operativo) è fatto bene, considerato l'enorme numero di istruzioni e di passaggi da eseguire, non sono sicuro che avere i sorgenti aiuti. Se non ricordo male, Windows 2000 nudo e crudo (senza, cioè, drivers e software di terze parti) aveva ben 5 milioni di righe d'istruzione.
Studiarle tutte non credo sia un buon modo per sfondarlo
Non oso pensare quante siano le linee di istruzione di un software moderno.

Da quello che sapevo io, chi cerca i bug lo fa con attacchi mirati (vedi quel concorso annuale che ti fa vincere il computer che riesci a violare: mica hanno il codice sorgente davanti) e, in base alle risposte del sistema, si affina il tiro fino a provocare l'exploit (odiato dall'hacker purosangue perchè "rumoroso") o, comunque la violazione del sistema. Conoscere o meno il codice è irrilevante perchè troppo lungo da studiare: si perderebbe troppo tempo e costerebbe troppo.
Siamo alle solite, avevo fatto una domanda tecnica, ma si preferiscono le guerre di religione ... don Spencer, aiutaci tu! :)
"Guastulfo: il binomio closed = sicuro, open = insicuro non l'ho mai proposto"
e sotto scrivi:
Poi ripeto il punto non è che l'open non possa essere sicuro: se segue certi standard che sia open che sia closed offre certe garanzie. IL PUNTO E' CHE NON SEGUE CERTI STANDARD.
Che stride con quanto affermato. Ad ogni modo affermi che l'open, nella sua interezza, non segua nessuno standard? Posto che sarebbe un po' difficile dimostrare che anche solo la maggior parte dell'open non segue tutti gli standard (e comunque bisogna vedere, perché se ci lavora solo un team di 5 persone certi standard non sono utili, dividi un team di 5 persone in tester, programmatori, progettisti, analisti ecc). Il closed li rispetta? sarei davvero curioso di sapere quanti progetti grandi e medi CLOSED seguono l'iso 9001, che rimane spesso sulla carta (in Italia poi)....
Basti vedere anche le ultime derive della programmazione agile.....

3) Lufo: troppo lungo, che sia controproducente significa dire "closed = insicuro", cosa che neghi tu stesso che sia stata detta, quindi c'è un problema di fondo...
Vuol dire solo approcciarsi in modo errato al problema, ma uno può anche sviluppare un software closed usando algoritmi pubblici, nessuno lo vieta. Il punto è: è utile mascherare l'algoritmo? No. Da qui il fatto che codice sia pubblico è un parametro "negativo" ininfluente, perché se è più facile scoprire un bug per terzi, vuol dire che terzi sanno anche come risolverlo. Microsoft e google fanno sicuramente bene ad offrire del denaro per questo genere di lavoro, perché se no lo farebbero in pochi e a tempo perso, oppure per interessi loschi. Tuttavia è un altro aspetto del discorso. È un punto positivo poter accedere direttamente al codice? Io dico di sì, tu no, ma non puoi dire che sia un aspetto negativo, contraddici decenni di informatica che affermano che un algoritmo, le istruzioni e altro se pubbliche NON devono influenzare nulla.

@van Fanel
Dipende se l'aggiornamento è compatibile. Ad ogni modo conviene cambiare la distro. Lubuntu gira su hardware con specifiche veramente basse, per cui non vi sono problemi. Considera che gira su un pc di 10 anni fa, con pentium IV, a cui era stato solo aumentata la ram anni fa. Dischi IDE come bonus :-D
Guastulfo: l'ultima volta che avevo contato (eheh) si era nell'ordine dei 60 milioni di righe di codice. Questo però non significa che te li debba andare a spulciare tutti =) Se in ogni sistema complesso a ogni difetto ti dovessi passare tutto in rassegna mi immagino la manutenzione degli aerei di linea: farebbero prima a buttarli che a verificare perché s'è accesa una data spia :D

Così come nell'automobile se non ti va una freccia sai già dove andare a parare allo stesso modo su Hearthbleed se vedi che la comunicazione criptata in HTTPS fa le bizze sai già che si tratta di OpenSSL. Poi facendo caso in che contesto accade ti fai già un'idea di quale parte del codice riguarda. E quindi inizi a guardare. Come fanno gli sviluppatori veri =) Hai anche a disposizione gli stessi strumenti di debug, per cui sei anche enormemente agevolato.

Ah, tutto questo ovviamente... ...se usi un sistema open ihhihi
@lufo
Grazie per la risposta!
Ad ogni modo conviene cambiare la distro. Lubuntu gira su hardware con specifiche veramente basse, per cui non vi sono problemi. Considera che gira su un pc di 10 anni fa, con pentium IV, a cui era stato solo aumentata la ram anni fa

Infatti Lubuntu era stata la mia prima scelta, ma avevo avuto problemi (non mi ricordo quali, l'avevo provata l'anno scorso). Xubuntu 12.04 era l'unico che aveva funzionato (la 13 no, ora che ci penso mi sa che era questione di processori no-PAE non più supportati dalla 13 in poi) e poi ci avevo schiaffato sopra il desktop LXDE così "sembra" Lubuntu. Non ho neanche avuto bisogno di aumentare la RAM (512 MB sono bastati). Nota di colore: per installare qualsiasi cosa su quel portatile bisogna fare i salti mortali perché ha il lettore CD rotto e non supporta il boot da penna USB. La soluzione più ovvia sarebbe stata un lettore di CD esterno USB, ma non ce l'ho, per cui ho risolto facendo boot da un lettore USB di floppy 3,5 (!!!) con un floppy GRUB dal quale ho ri-fatto il boot da penna USB con Unetbootin!

p.s. sarei davvero curioso di sapere quanti progetti grandi e medi CLOSED seguono l'iso 9001, che rimane spesso sulla carta (in Italia poi)....
Basti vedere anche le ultime derive della programmazione agile.....


Firulì, firulà ... Solito dito nel colletto ... Ehm, mi cercano altrove ... firulììììì....
Scusate, mi aggancio all'ultima frase per una piccola precisazione che volevo già fare ma mi è sfuggita: si sta parlando di OS e quindi quando parlo di closed ovviamente il raffronto è con i colossi tipo Microsoft che al di là delle simpatie / antipatie sa fare il suo mestiere.

Se andiamo su scala più piccola è una guerra tra poveri, viene scritto software mediocre in modo del tutto democratico (aperto o chiuso che sia). E' anche vero che produrre codice di qualità ha dei costi insostenibili ai più (per non parlare del know how necessario). Così come è vero che sulla scala / sui mercati su cui operano le software house di medio piccole dimensioni l'open praticamente non esiste, quindi diventa anche difficile fare raffronti.

Per inciso: tenere ben chiuso il codice di software scritto alla bell'e meglio e che non ha una diffusione tale da attirare troppe attenzioni credo sia un grosso vantaggio... Credo che il 98% del software scritto a quel livello verrebbe altrimenti aperto come una cozza nell'arco di poco tempo
"Quanti bug altrettanto devastanti ci sono stati in sistemi closed?" me ne ricordo solamente due. E uno era un malware, quindi un PEBCAK (Iloveyou) mentre l'altro era Blaster...
"Posto che sarebbe un po' difficile dimostrare che anche solo la maggior parte dell'open non segue tutti gli standard (e comunque bisogna vedere, perché se ci lavora solo un team di 5 persone certi standard non sono utili" Scemo io a essere convinto che gli standard di qualità servono pure se sviluppo mentre sto seduto sul candido trono a casa mia....

Ma sta di fatto che i bug succedono sempre, tendenzialmente a me quando dico "voglio provare a usare linux per..." e devo compilare qualcosa: le istruzioni dicono sempre e solo di fare ./configure, poi make e make install ma non funzionano mai...

Seriamente, i bug ci sono e la correzione dev'essere veloce appena si scovano. Open o closed.
@Fx
[...]viene scritto software mediocre in modo del tutto democratico (aperto o chiuso che sia).

Eccome se lo so. Ho perso il mio primo lavoro per questo :-D

A quell'epoca ero un giovine che non si faceva mai i fatti suoi ma amava ravanare dentro i sistemi operativi per andare dove mai mano dell'uomo aveva messo piede.

Avevo da poco letto un libricino che parlava di filtro dei dati (o qualcosa di simile). Nel libro era scritto che molti software non mettevano "trappole" per bloccare caratteri speciali pericolosi che potevano violare un database se inseriti nei campi al posto dei dati reali.
Allora pensai di sperimentare l'uso di caratteri escape (si chiamano cosi?) all'interno dei campi della banca dati su cui lavoravo anch'io. E... olplà! I caratteri funzionavano alla perfezione.
Non contento, mi collegai al server mediante terminale e digitai le credenziali di sysadmin di default del database. E.. cosa successe? Fu respinto il login? Macchè! Entrai nel database come sysadmin.

Da bravo ragazzo qual ero, andai al mio capo e spiegai il problema. Naturalmente il mio capo non ci capì nulla. Meglio capì solo che avevo acceduto a dati riservati a cui non dovevo accedere (non era vero, mi ero solo loggato) e riferì la cosa ai suoi capi. Mi ritrovai nel giro di 24 ore davanti ad una sorta di commissione disciplinare in cui mi urlarono letteralmente varie cose, tra cui di denunciarmi perché avevo commesso un reato penale in modo da indurmi a presentare la lettera di dimissioni (oggi non sarebbe andata così ma all'epoca non ero neanche laureato, ero lontano da casa e così riuscirono a intimidirmi).
Ho poi saputo da ex colleghi che chi aveva scritto il software era "strettamente collegato" ad uno dei grandi capi ed evidenziare la pessima qualità del software era pericoloso quanto bersi due litri di cicuta.
E' vero che all'epoca (sono passati, credo, 15 anni) la sicurezza non era di moda, ma errori simili in un database che gestiva informazioni di un intero consorzio e a cui si collegava anche gente da fuori, erano piuttosto gravi. Un concorrente avrebbe potuto rubare i dati o alterarli o, ancora, cancellarli.

Ora, ovviamente, ci penso bene prima di esporre un qualche problema a un mio superiore. In fondo non è la mia mansione e se mi chiedono un parere (sanno che mi diletto ancora a smanettare ma non lo faccio più sul posto di lavoro :-) ) raramente dico tutto ciò che penso. Non conviene. Errare umanum est, perseverare autem diabolicum :-)
Analizzando il log di APACHE del mio piccolo server web casalingo ho notato che qualcuno ha provato la falla beccandosi un 403..pensa un po' che robe!
@Lupo
"Quanti bug altrettanto devastanti ci sono stati in sistemi closed?" me ne ricordo solamente due. E uno era un malware, quindi un PEBCAK (Iloveyou) mentre l'altro era Blaster...

Che dici Lupo? TU mi mescoli i concetti di bug e malware in una frase?
Iloveyou era un malware ma non sfruttava alcun bug (a differenza di altri malware come Blaster, Sasser, SQLSlammer, Conficker, Stuxnet, etc, tutti malware che sfruttavano uno o più bug) ... se mai sfruttava, oltre ovviamente al PEBCAK da te citato, alcune "feature" generalmente inutili per l'utente medio :)
Tutti o quasi i malware sfruttano falle detivanti da bug, gli altri sfruttano codice non sicuro perché scritto male :-)
@illupo della luna
Scemo io a essere convinto che gli standard di qualità servono pure se sviluppo mentre sto seduto sul candido trono a casa mia....
Rileggi il mio messaggio, hai capito cavoli, quando dicevo mele.
Gli standard del mondo dell'informatica, o comunque le "best practices", sono collegate anche alla mole di lavoro da svolgere e al numero di membri del team di sviluppo (oltre che alle richieste del committente, ovviamente).
Il fatto stesso che tu lavori da solo è una violazione delle "best practices" che prevederebbero l'adozione di almeno una persona diversa per ciascuna delle seguenti figure:
- analista
- progettista
- programmatore
- amministratore
- responsabile
- tester
Quindi, prima di scrivere frasi come "scemo io che" ragioniamo un attimo. La letteratura informatica stessa invita aziende e informatici ad applicare in modo ortodosso determinati standard e burocrazia quando vi è una possibile utilità.
Ovviamente determinati standard sono _sempre_ utili (vedi commenti sul codice), ma non tutti, perché alcuni sono efficaci e utili solo per lavori di una certa mole (che andranno identificati)

ciao

P.S. E non direi che "tutti o quasi" i malware sfruttano vulnerabilità software. Molti sfruttano una falla nota come "PEBKAC", ma quella non è un problema del software, è una condanna :-D
"open o closed la differenza la fa la qualità del codice."

Infatti secondo i test di Coverity Scan (che analizza proprio la qualità del codice) il valore medio di bug ogni 1000 linee di codice è inferiore nel software open source (0.59) rispetto a quello proprietario (0.71). Addirittura LibreOffice arriva al valore record di 0.08 (l'anno scorso era 0.8, quindi c'è stato un miglioramento impressionante nel giro di un anno)!!
Magari, invece di parlare per stereotipi inculcati da chi promuove il software non-libero, sarebbe bene prima documentarsi su dati oggettivi.
"For the 2013 Coverity Scan Report, the company analyzed code from more than 700 open source C/C++ projects as well as an anonymous sample of enterprise projects"

Se confrontiamo mele con pere, si - al di là delle considerazioni sul valore che ha un test automatico, se fosse tutta lì la questione fai girare un programma e correggi i bug riportati. Significa che lì passano i progetti top del mondo open e i progetti di software house di medie dimensioni per il closed. Il giorno che si farà un paragone scientifico Linux vs Windows ne riparliamo (se la distanza di qualità misurata tra progetti sconosciuti closed, sulla cui bontà del codice non ci scommetterei mezzo euro, e progetti di livello mondiale open è risicata dubito vivamente ci possa essere storia con il codice di una software house di livello mondiale - onestamente mi sarei aspettato un delta molto più ampio, su una metodologia di test del genere, anzi mi inquieta un po' seppur non mi stupisca).
@lufo
E non direi che "tutti o quasi" i malware sfruttano vulnerabilità software. Molti sfruttano una falla nota come "PEBKAC", ma quella non è un problema del software, è una condanna :-D

Ma infatti l'aveva detto :) E nel caso di Iloveyou e altri simili, oltre al PEBKAC sfruttano una discutibile "feature", cioè il fatto che MSGuardaFuera eseguiva tranquillamente gli allegati eseguibili quando l'utente li doppiocliccava (non se lo faccia ancora, l'Outlook che ho in ufficio è configurato per bloccare tout court tali allegati, ma non se è di default o un'impostazione attivata da IT). Tra l'altro, nel caso di Iloveyou, se Outlook l'avesse aperto come file di testo (perché era uno script, non un binario) avrebbe subito fatto capire l'inganno.

p.s. Anche un'azienda Microsoft-oriented (come la mia) non può ignorare il problema, è stato necessario aggiornare alcuni apparati di rete.
uff, per due volte ho scritto "non se" intendendo "non so se" ...
Accademia, Accademia, dove sei? Qualcuno di voi, bambini, l'ha per caso visto?