skip to main | skip to sidebar
45 commenti

Heartbleed, falla di sicurezza senza precedenti ferma Internet. Come difendersi

Sai che una falla è grave
quando ha un logo tutto suo.
L'articolo è stato aggiornato dopo la pubblicazione iniziale.

C'è un forte panico mediatico intorno a Heartbleed, la falla gravissima nel software di autenticazione e cifratura OpenSSL che permette di rubare in modo invisibile password di utenti e identità di siti: proviamo a fare un po' di chiarezza.

Il problema, sensazionalismi a parte, è veramente serio. Bruce Schneier, uno dei massimi esperti mondiali di sicurezza, l'ha definito senza mezzi termini “catastrofico”. Le autorità svizzere, specificamente la Centrale d'annuncio e d'analisi per la sicurezza dell'informazione MELANI, hanno pubblicato un dettagliato comunicato (in italiano, francese e tedesco).

Le cose di base da sapere sono queste:
  • Heartbleed è il nome informale dato a un errore di programmazione (CVE-2014-0160) che da due anni è presente nella libreria software crittografica OpenSSL versione 1.0.1, che è usata o è stata usata da due terzi dei siti Internet del mondo per proteggere le comunicazioni sensibili (principalmente scambi di password) e per autenticarsi (far chiudere il lucchetto nei browser). Il nome è un gioco di parole su heartbeat (un termine tecnico che descrive un aspetto del funzionamento di questa libreria).
  • Almeno mezzo milione di siti risulta essere vulnerabile.
  • L'errore è già stato corretto nella nuova versione di OpenSSL (la 1.0.1g).
  • Si presume si tratti di errore e non di sabotaggio intenzionale.
  • L'errore è stato scoperto indipendentemente da due gruppi di ricercatori (Riku, Antti e Matti a Codenomicon e Neel Mehta di Google Security) e annunciato pubblicamente il 7 aprile scorso.
  • Spetta ai responsabili della sicurezza dei singoli siti aggiornarsi installando la nuova versione di OpenSSL.
  • L'errore consente a un aggressore, senza interagire con i computer/dispositivo della vittima, di acquisire dati riservati (mail, password, documenti, numeri di carte di credito) trasmessi dai siti che usano OpenSSL.
  • Cosa ancora più grave, l'errore potrebbe consentire a un sito gestito da un aggressore di spacciarsi per un sito attendibile in modo assolutamente realistico (lucchetto chiuso, https).
  • Sono a rischio webmail, social network e anche VPN.
  • Non sappiamo quanto questa falla è stata sfruttata, perché l'aggressione spesso non lascia tracce. Dobbiamo presumere il peggio. Alcune tracce indicano che viene sfruttata da mesi.
  • Yahoo, Instagram, Tumblr, Dropbox, Minecraft, Flickr, Imgur sono fra i principali siti che risultano essere (o essere stati) vulnerabili: i ricercatori hanno dimostrato di riuscire a estrarre password e indirizzi di e-mail di Yahoo sfruttando questa falla. Tutti i siti citati ora sono a posto e non sono più vulnerabili.
  • Non ci sono aggiornamenti di sicurezza da installare sui computer, tablet o telefonini di noi utenti, ma chi ha un computer che ospita un sito Web oppure un NAS dovrà verificare se sta usando la versione vulnerabile di OpenSSL.
  • Non fa differenza se usate Mac OS, Linux, Windows, Android, iOS e se usate un computer o un tablet o uno smartphone: siamo tutti vulnerabili allo stesso modo.
  • Ci vorrà tempo perché la falla sparisca da Internet: i singoli siti devono installare la versione aggiornata del software OpenSSL e poi devono generare una nuova coppia di chiavi di sicurezza e aggiornare il proprio certificato SSL. Considerata la ressa che ci sarà per fare queste cose presso le autorità che emettono certificati, il problema si trascinerà probabilmente per alcuni giorni.
  • La parte più difficile sarà rimuovere la falla da NAS, firewall, sistemi embedded e altri dispositivi. Cisco, per esempio, ha annunciato che almeno tredici dei suoi sistemi di telefonia IP e server di comunicazione e messaggistica sono vulnerabili e vanno aggiornati.

Le cose fondamentali da fare, invece, sono queste:
  • Controllate se i siti che visitate sono vulnerabili o si sono aggiornati, immettendone il nome in ssllabs.com/ssltest oppure filippo.io/Heartbleed/.
  • Se un sito risulta vulnerabile, non interagite con esso fino a che non si aggiorna. Non cambiate la vostra password: è inutile se il sito non si aggiorna. La nuova password verrebbe letta dagli aggressori.
  • Se un sito risulta non vulnerabile, visitatelo e cambiate immediatamente la vostra password.
  • Non usate la stessa password per siti differenti: se lo fate, mai come oggi è il momento di smettere di essere così pigri e imprudenti.
  • Non fidatevi di mail o altri messaggi che vi invitano a cliccare su un link per aggiornare le vostre password: sono quasi sicuramente trappole di criminali.
  • Non seguite link a siti presso i quali avete un account: digitate a mano il nome del sito nel vostro browser.
  • Se avete NAS o altri server personali esposti a Internet, aggiornateli appena possibile.

Infine, alcune considerazioni generali:
  • Il fatto che la falla sia in un componente software open source non è una dimostrazione dell'inaffidabilità dell'open source. Anzi, il fatto che il codice di questa libreria sia aperto e ispezionabile da chiunque ha agevolato la scoperta e la correzione dell'errore. Non è detto che errori come questo non ci siano anche nel software chiuso, e se ci sono possono essere scoperti solo da un numero molto ristretto di addetti ai lavori.
  • Si sa chi è il “colpevole”: lo sviluppatore tedesco Robin Seggelmann, che ha materialmente inserito la modifica errata il 31 dicembre 2011 alle 23:59:57 (almeno stando ai log), ma anche il suo collega revisore Stephen Henson che non ha visto l'errore.
  • Gli errori di questo genere avvengono perché un elemento vitale della sicurezza come OpenSSL viene gestito da un numero molto modesto di esperti volontari non pagati. Se le aziende che usano questo software per fare milioni di guadagni donassero qualcosa al progetto OpenSSL, avremmo più occhi a sorvegliare la qualità del software.
  • Allo stato attuale sembra improbabile che l'errore sia stato introdotto intenzionalmente da parte di agenzie governative come NSA per facilitare le intercettazioni, ma è presumibile che queste agenzie abbiano notato e sfruttato la falla.


Fonti aggiuntive: Ars Technica, MELANI. Ringrazio Luigi Rosa per alcune info tecniche.
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 (45)
Ma son stati vulnerabili anche i siti a doppia autenticazione? Tipo quelli che si legano a dispositivi, app o browser su macchine specifiche e usano seconda autenticazione via sms o dongle per chiavi usa e getta? Non credo e considerato che la carta che uso è ricaricabile alla bisogna un bel … esticazzi … ci sta …
Paolo,

Ottimo articolo che descrive una pessima situazione.

Un paio di appunti:
- c'é un periodo sospeso ("Le autorità svizzere, specificamente la Centrale d'annuncio e d'analisi per la sicurezza dell'informazione MELANI (comunicato in francese e tedesco).")
- "i singoli siti devono installare la versione nuova di software" suona male.

Se già non l'hai visto, qui trovi lo spiegone tecnico del bug: http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

Grazie per il tuo lavoro,
saluti,
Davide
Segnalo che anche LastPass offre il servizio di verifica dei siti. Inoltre agli utenti del servizio è offerto un tool di check della sicurezza delle proprie password che adesso include anche un controllo per Heartbleed.
Mi lego alla domanda di prima:
1. cosa fare per siti con two-factor authentication tipo google, twitter, wordpress, facebook...?
2. cosa fare con i siti bancari provvisti di token fisico per l'autenticazione?

Grazie
Nella prima frase hai messo un cervo al posto del cuore.
Ho fatto il test dell'aera login del sito della mia banca e succede una cosa "divertente":
per filippo.io è tutto OK, mentre ssllabs.com mi da una F e un "Warning: Inconsistent server configuration".

Nel dubbio eviterò di collegarmi per quanto possibile. Il problema è che nopn posso recarmi in banca per ogni operazione, rischierei di passarci ore ogni giorno e non posso permettermelo (tradotto: i miei capi non lo permetterebbero :-) ).
Cosa succede se utilizzo l'account di Google per accedere ad esempio a Flikr ecc..?
Manca però un dettaglio fondamentale: questo bug permette di decifrare le comunicazioni protette, ma prima devi INTERCETTARE la comunicazione che ti interessa.

In altri termini la questione viene posta come se essere vulnerabili significa che possono entrare e leggere tutte le credenziali memorizzate. Del tutto falso. Essere vulnerabili significa che nella peggiore delle ipotesi è come se tu fossi in http, e non in https.

Quanto impatta nella realtà una connessione non protetta? Dipende. Se sei collegato a una rete (esempio: ufficio), e c'è qualche collega sufficientemente abile (suggerimento: no) e sufficientemente scemo 1) da usare il sistema complicato al posto di un keylogger software o hardware o altre trovate estremamente più semplici 2) che vuole rischiare il posto di lavoro per rubarti la password di Facebook si, sei a rischio. Se sei a casa dubito.

Ma soprattutto: parliamo solo di http? Quanti accedono alla casella di posta con connessione protetta (vogliamo fare filosofia? Dovrebbero assolutamente farlo. Ma a me della filosofia frega poco, la realtà è che tantissimi non lo fanno)? Quanti accedono (e qui faccio una pernacchia dal ridere) al loro spazio FTP con protocollo sicuro?

Quindi: un disastro se accedi a Facebook o la posta di Yahoo con una connessione che SE INTERCETTATA può POTENZIALMENTE essere decriptata, ma nel mentre ti colleghi alle tue caselle email trasmettendo tutto in chiaro (user, password, posta).

E magari nel mentre non hai l'antivirus aggiornato, hai duecentoventi malware diversi installati, clicchi in ogni dove e apri qualsiasi cosa, hai come password "password" e ce l'hai anche scritto su un post-it appiccicato al monitor per non dimenticartelo.

Continuo a ripetere che queste sono notizie per gli addetti ai lavori. Noi abbiamo un tot di server e di virtual machine, a noi si, ci interessa. Per la massa cambia niente, tanto per un account che viene esposto con questa tecnica ce ne sono centomila esposti con quelle solite (molto più efficaci, pratiche ed economiche).
Fx, dimentichi forse un particolare altrettanto importante: il phishing "certificato". Si potrebbero creare siti-trappola con l'attestato di falsa (in questo caso) sicurezza visivamente dato dall'https e dal lucchetto chiuso.
Per chi usa Centos occorre aggiornare openssl alla versione 1.0.1e-16.el6_5.7 o superiore. la 1.0.1g verrà rilasciata quando RedHat rilascerà tale versione. Ovviamente la 1.0.1e corregge il bug. NOTA: la 1.0.1e 5.0.x e superiori hanno il bug, ci vuole 5.7+
@Paolo Attivissimo

Ciao Paolo, perdona l'OT volevo segnalarti ques'articolo http://www.tio.ch/News/Ticino/786310/Pedopornografia-sul-mio-pc-ma-io-volevo-solo-musica-e-film/

Ciao! :)
@Guastulfo se hai sottomano un interprete Python puoi scaricare uno script da http://siamogeek.com/wp-content/uploads/2014/04/heartbleed.zip che verifica se la tua banca e' differente e ti fa il dump dei dati che e' riuscito a catturare se la tua banca, oltre che differente, e' anche trapanabile.
"Se avete NAS o altri server personali esposti a Internet, aggiornateli appena possibile" se dipendesse da me lo farei volentieri ma mi tocca aspettare che si sveglino alla Western Digital. Ho bisogno di un nuovo NAS?

Comunque non ho capito bene una cosa.. questo bug consente di connettersi tramite SSH a un server vulnerabile senza avere le credenziali e ficcanasarci dentro oppure consente di fare un attacco man-in-the-middle?
Quindi per sicurezza è opportuno cambiare le password di tutti i servizi che uno usa? Paypal, homebanking, Apple ID, Account Google?
Paolo, alcune note su quanto hai scritto:

- L'articolo di seacat è stato corretto indicando che ci sono altri tool che producono i pattern del bug heartbleed, quindi non è necessariamente vero che la falla viene sfruttata da mesi, e molto proabibilmente non è così.
- Sfruttare la vulnerabilità per ottenere dati *mirati* è quasi impossibile. O meglio è banale sfruttare la vulnerabilità per ottenere porzioni casuali di memoria dal server (fino a 64k ad ogni tentativo) e non c'è modo lato server per capire se questo stia accadendo (nell'ipotesi di essere ancora vulnerabili) o se sia accaduto in passato, in quanto la richiesta non lascia tracce sui log di sistema. Nonostante questo è impossibile ad esempio leggere un dato specifico (tipo leggi la password dell'utente tizio@example.com) in quanto le porzioni di memoria restituite sono casuali e differenti ad ogni richiesta, per cui sicuramente con la vulerabilità si espongono dati sensibili del server, ma non è automatico che in un dato server sia stata compromessa la propria password così come non è detto che sia stato compromessa la chiave privata che protegge il certificato SSL.
- I siti delle banche spesso e volentieri girano su piattaforme java che non sono affette dal bug.
- Rimangono validi tutti gli altri consigli, in particolare quello di non riutilizzare *mai* la stessa password su più di un sito.

Ovviamente un sito preso di mira da un cracker (e gli ultimi 2 giorni sono stati una festa in questo senso) viene bersagliato da centinaia di migliaia di richieste che sfruttano il problema, e tutto quello che viene scaricato dal server viene poi analizzato in seguito per ricostruire quanti più dati possibile. I siti più esposti in quanto più appetibili saranno stati bombardati di richieste per cui è plausibile che molti (ma non si sa quanti e quali) dati siano stati compromessi anche in funzione di quanto tempo sia rimasto esposto il sito. Da quest'ultimo punto di vista yahoo è stato uno dei più lenti a reagire (vedi ad esempio https://twitter.com/WarrenGuy/status/453510021930680320/photo/1).

Nel campo della sicurezza informatica se non si è certi che un dato sia stato compromesso o meno, si deve assumere che lo sia stato, per cui rimane comunque valido il consiglio di cambiare le password sui siti compromessi (e su tutti quelli in cui si usava la stessa) dopo che essi siano stati messi in sicurezza.
Per la cronaca, Synology ha reso disponibile oggi il fix per i propri NAS: http://www.synology.com/en-global/releaseNote/model/DS1511+
@Luigi Rosa
Grazie. :-)
A casa ho una macchina virtuale linux dove ho il "pitone". Farò subito una prova.

E' importante per me perché se provassi a spiegare ai capi che non è sicuro connettersi alla banca on line per via di heartbleed penserebbero che ho inventato una scusa per farmi una passeggiata; se rubassero i soldi per colpa di heartbleed, non mi crederebbero e mi darebbero la colpa.

Giusto per completezza, se faccio qualcosa che va oltre il mio dovere mi ricompensano con "mille grazie" (milioni di grazie no: sarebbero troppi). Ma tant'è. Oggi è già tanto avere un lavoro.
@Fx: non è solo come se fosse http invece che https: la memoria stessa del server è perfettamente leggibile da chiunque: significa le password temponaneamente memorizzate possono essere lettere (e un server dovrebbe memorizzare solo una password quanto basta per fare l'hash)... Quindi l'idea è che se ora accedo al mio ebanking, la mia password viene memorizzata sul server ed è potenzialmente leggibile. Per questo è molto più grave di GotoFail...
Mashable ha pubblicato una lista dei principali siti, con informazioni sul loro stato rispetto alla vulnerabilità e opportunità di agire d'urgenza sulla password (che è comunque consigliabile, come hai giustamente sottolineato):

http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/
Filippo: falso. Il bug permette di leggere solo nella memoria del processo, ovvero OpenSSL. E' per quello che tutti parlano di chiavi private (ovvero l'unica cosa che di interessante ci può essere nella memoria di quel processo), altrimenti parlerebbero tutti della password di root, non credi?
Una cosa mi lascia SCONCERTATO: uno dei server di PayPal si è beccato una "F", in quanto a bontà della sicurezza. "F". Cioè: "schifo".
https://www.ssllabs.com/ssltest/analyze.html?d=paypal.com
@Fx: hai ragione. Però puoi leggere la sessione OpenSSL di un'altro utente (che magari contiene la sua password e la sua mail perchè spedita tramite POST; eccetera), senza dunque necessitare di un Man In The Middle.
Non so sicuro che c'entri, ma forse sì: qualche giorno fa, ho ricevuto uno dei soliti messaggi phising di (finta) paypal ("il tuo conto è stato bloccato, per sbloccarlo clicca qui, ecc."). Solo che questa volta il messaggio era eccezionalmente ben fatto e risultava venire da "service@paypal.com", cioè dall'indirizzo vero.

Naturalmente mi sono ben guardato dal cliccare su alcunchè, ho segnalato la cosa a paypal, e dopo 24 ore mi hanno ringraziato e il messaggio risulta bloccato e non più visibile anche sulla mia casella di posta. Secondo voi c'è un rapporto?
Quando uno è un genio:
http://xkcd.com/1354/
"Hai sentito, Ora che non sarà più aggiornato, sono preoccupato" così pensa il normale utente italiano, ignaro che gli aggiornamenti sono proprio quella funzione che ha disabilitato nella sua copia pirata di Xp. E mentre pensa questo, clicca ancora una volta NO, all'ennesima richiesta di aggiornamento di flash.
Ma Heartbleed, openSSL... Open cosa? sono nomi troppo difficili da pronunciare,,, Scusate ora ritorno a Facebook.
:-)
@Andrea Montesi
Quando uno è un genio:

La prossima volta che non capisco una cosa e mi chiedono: "vuoi il disegnino?"
risponderò
"SI'"
:-)
La spiegazione e' chiara, ma trovo geniale questo fumetto che spiega tutto alla grande, piu' di mille tecnicismi


http://xkcd.com/1354/
Ho ricevuto un messaggio su cineblog tramite disqus
http://engineering.disqus.com/2014/04/10/heartbleed.html
Per fortuna non ho fatto la stronzata di fidarmi.
Ho letto la dichiarazione dell'autore del codice responsabile del bug. Diceva in buona sostanza che si, è sfuggito sia a lui sia a chi aveva il compito di verificare il codice.

Fatemi capire. Codice usato dal 66% dei web server mondiali viene scritto da pinco e verificato da pallino, e quindi finisce in produzione? Questo è il tanto decantato open? Ma fatemi il piacere, piantiamola di difendere ideologicamente il binomio open e sicurezza che questo episodio riconferma ciò che è di fronte agli occhi di tutti: la qualità del codice open è estremamente eterogenea. Il problema è che non basta un kernel curato per fare una piattaforma sicura. Servono procedure rigorose.

Diciamo che l'open è gratis, accessibile, flessibile. La sicurezza lasciamola perdere, va là.
"31 dicembre 2011 alle 23:59:57", non aveva altro da fare in quella data?
@FX: sì è funziona così anche nel closed: software usato dal miliardi di persone, fatto da Tizio, controllato da Caio.
Solo che nel closed se c'è un errore se ne può accorgere solo uno dei pochi che ha accesso al codice; nell'open se ne può accorgere chiunque.
È ora di finirla di difendere l'indifendibile!
l'NSA sapeva?

http://www.webnews.it/2014/04/12/heartbleed-nsa/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Webnews
Premesso che nel closed indagare un bug è estremamente più oneroso, su quei livelli solo dei pazzi avrebbero degli standard qualitativi di così basso profilo. Se avessi vagamente idea di come funzionano le cose nelle grosse software house (da MS a tutte le altre) non parleresti così. Il punto è che a queste si dà addosso per pregiudizio e l'open lo si difende per ideologia. Non a caso alla fine a sentire certe campane l'open ha solo vantaggi: più sicuro, più economico, flessibile, portabile, personalizzabile, eccetera eccetera. E ovviamente quando uno sostiene che una cosa ha solo plus e l'altra ha solo minus sta cercando di fare una cosa sola: di venderti quella cosa. Non necessariamente per profitto economico, eh... Magari fa l'evangelista perchè ha la sfortuna di crederci davvero.
Il discorso closed vs opensource o il contrario che qualcuno nei commenti ha avanzato in questo caso è completamente ridicolo.
Che Fx sia in torto lo dimostra il fatto che ogni mese windows è costretta a rilasciarti degli aggiornamenti, per venire incontro a dei bug del loro sistema, che talvolta si sono dimostrati ben più gravi anche di questo caso.
Qui l'unica cosa che sorprende è che nonostante il codice sia opensource, l'errore sia saltato fuori soltanto ora, con una tempistica che invece solitamente capita proprio nei progetti cloused.
"Solo che nel closed se c'è un errore se ne può accorgere solo uno dei pochi che ha accesso al codice". Non esattamente. Anzi è molto difficile che si veda l'errore dal codice in produzione: ognuno parte dal presupposto, corretto, che il codice sia stato verificato a monte e quindi NON lo controlla. Già è difficile rimettere mano nel proprio codice a distanza di tempo, capire del codice magari complesso che interagisce con un sacco di altra roba da zero è decisamente difficile. Oltretutto. chi ci dice che non ci siano stati programmatori che, accortisi dell'errore, l'hanno banalmente patchato sulla propria copia e fine?

A quanto ne so, i bug di questo genere si scoprono sulla base degli exploit che saltano fuori usandoli, e poi si cerca a ritroso di capire che pezzo di codice è il colpevole.

Consiglio ai curiosi questo libro: http://books.google.it/books/about/L_arte_dell_hacking.html?id=INh9YL62uA0C&redir_esc=y che pur avendo diversi esempi pratici. spiega molto bene come "ragiona" chi cerca di sfruttare le vulnerabilità dei programmi: scoprirete che alla fine del codice sorgente se ne fanno molto ma molto poco.

"he Fx sia in torto lo dimostra il fatto che ogni mese windows è costretta a rilasciarti degli aggiornamenti"
Anche linux. E anche più frequentemente, se necessario.
Dirò di più, Ubuntu esce con una nuova release ogni sei mesi... cosa credete che faccia? Bugfix e patch.
Le altre distro non sono da meno, CentOS, Debian e Ubuntu, per dire quelle su cui metto mano hanno un sistema di controllo degli aggiornamenti automatico molto ben fatto..

Vai sulla tua Ubuntu e fai
# sudo apt-get upgrade

Buon divertimento :D
Ha già risposto Lupo, grazie. Onestamente preferirei non continuare la discussione con chi parla della frequenza degli aggiornamenti senza manco sapere quale sia quella su una distro Linux (e poi come queste siano eterogenee e quindi si debbano applicare delle distinzioni per lo meno tra consumer e enterprise, ma anche tra tipologia di installazione scelta).

Per inciso, se parliamo di bug sarebbe interessante dibattere sull'evolversi nel tempo dei bug aperti su Windows, Linux e Os X. O meglio, sarebbe propedeutico per aprire bocca sul resto.
ma questo Robin Seggelmann a capodanno non aveva niente di meglio da fare?
@il lupo della luna
ed hai ben ragione, e ti darei 1000 euro se trovi la riga dove ho scritto che Linux invece non ha bisogno di aggiornamenti.
Sottolineavo, che contrariamente di quantosi vuol far credere in altri commenti, anche il closed come ad esempio, Windows ha bisogno di aggiornamenti. Pochi? Non direi. Basta vedere l'assurda dimensione dei vari service pack e aggiornamenti mensili.
Perfettamente d'accordo anche su quanto sottolineavi in merito a come sia difficile trovare gli errori nel codice closed.
Prendersela in questa situazione contro l'opensource è da folli.
Cristian, da quanto scrivi è evidente che ritieni il dover rilasciare aggiornamenti una cosa negativa.

Comunque, la facilità di trovare i bug tra programmi IN PRODUZIONE open source o closed source è ESATTAMENTE LA STESSA.

Nessuno, a meno di esigenze di sicurezza particolari (casi in cui usando closed source ti fai dare specifiche garanzie scritte dal produttore), si mette a controllarsi il sorgente della roba che installa in cerca di falle prima di installarlo. Non so se hai idea di quanto ci vuole a guardare il sorgente di una roba complessa e soprattutto capirlo: io poca, ma sicuramente non è una roba da due minuti.

L'unico vantaggio è che con l'open puoi verificare direttamente quale parte del codice sorgente viene sfruttata dall'exploit.. Che poi è relativo come vantaggio, non sono un programmatore ma so bene (dalle descrizioni degli exploit che leggo sempre con curiosità) che il più delle volte il problema non dipende da una singola porzione di codice (un singolo "programma" diciamo) ma dall'interazione di quello col resto del sistema operativo o degli altri programmi attivi nella macchina.

Comunque qua non è questione di "colpa" dell'open o del closed source: è che gli errori si fanno e non si trovano subito. Pensare che l'open source sia "intrinsecamente" più sicuro è una falsa sicurezza, visto che alla fine i mantainer "ufficiali" sono pochi.

Ah tra l'altro, domanda: questo bug di openssl ha colpito anche le versioni *BSD ? So che hanno dei cicli di rilascio lunghi proprio perché verificano in modo quasi maniacale ogni pacchetto.
Sarebbe carino evitare di trasformare i commenti nella solita e stantia flame-war MS vs Linux, anche perché openssl, licenza distributiva a parte, non c'entra nulla con linux; allo stesso modo gli aggiornamenti windows c'entrano come i cavoli a merenda con quelli linux, dato che il primo aggiorna solo SO e librerie collegate, mentre apt e company aggiornano anche (quasi) tutti i programmi installati, le librerie collegate e relativi bugfix; infine, closed e open sono semplici licenze distributive e in quanto tali non garantiscono né la qualità del prodotto né la sua sicurezza: ricordiamoci sempre la vecchia massima, il pc più sicuro è sempre quello spento e chiuso in un caveau sottoterra...
@Fx
ignorando tutta la polemica software libero o meno, volevo solo concentrarmi su ciò che hai detto nel tuo primo post e sottolineare che le tue affermazioni sono errate.

ciò che tu sostieni è che per usufruire di questo bug bisogna "intercettare" la conversazione.
poi dici che se si è vulnerabili è come se la conversazione fosse in http invece che https, in pratica una totale perdita della comunicazione cifrata in SSL.
a questo punto analizzi il problema secondo queste premesse.

purtroppo queste premesse sono scorrette.

come si può banalmente leggere su Wikipedia ( http://en.wikipedia.org/wiki/Heartbleed_bug ) questo bug non è un man in the middle.
è ben peggio.

il bug permette a chiunque di interrogare un qualsiasi server (con OpenSSL) a piacere con infinite richieste Heartbeat malformate. ad ogni richiesta si ricevono dati. molti inutili, ma ogni tanto potrebbe uscir fuori un nome utente e/o password (le normali form di login in POST) oppure chiavi di cifratura, fra gli scenari peggiori la chiave privata del server.
inoltre tutto ciò passando completamente inosservati.

da qui le conseguenze: con le chiavi private a questo punto è possibile effettuare attacchi man-in-the-middle e intercettare conversazioni cifrate oppure decifrare conversazioni precedentemente salvate o ancora utilizzare nomi utente e password per accedere account e avere accesso a dati (conversazioni aziendali, vita privata...) o movimento di denaro (amazon ad esempio) e così via.

senza contare che molte persone usano la stessa combinazione utente password su più siti.

indi per cui, tu puoi ripetere finché vuoi che sono notizie per gli addetti ai lavori, ma in un caso come questo credo sia giusto che TUTTI siano informati e possano quindi prendere le cautele del caso. (cambiare password su tutti i servizi che erano vulnerabili)

inoltre un caso come questo porta all'attenzione di tutti il discorso della sicurezza informatica.
(purtroppo i giornali esplorano l'argomento come se si parlasse a dei bambini di magie e contromagie, ma non è una cosa nuova)

sperando di non aver detto troppe cazzate,
peace.
Simone: probabilmente non mi sono spiegato bene e / o ho saltato passaggi e sono andato dritto al sodo, ma che il meccanismo sia esattamente come l'hai descritto tu non ci piove. Quello che intendo dire è che per sfruttare questa falla (si, tecnicamente sfruttarla significa recuperare le chiavi private, ma parlo di risultato finale) alla fine ti serve sniffare il traffico che ti interessa (non serve un man in the middle: per il man in the middle devi fare arp poisoning, sei visibile, eccetera... che basti solo sniffare è un vantaggio enorme), che poi con le chiavi puoi decifrare per l'appunto come fosse stato trasmesso in chiaro.

Il punto è che se sei sullo stesso network già hai un vantaggio enorme, e a meno che tu non sia su una rete di nerd paranoici puoi comunque fare di tutto (a proposito di man in the middle... fatemi indovinare che percentuale di utonti se entra sul sito della sua banca e gli esce l'alert che il certificato non è valido prosegue comunque?).

La realtà è che è un bug grave, ma le ricadute per l'utente medio poco rilevanti. E' molto peggio quando compromettono il db con le password di qualche grosso player, dato che una percentuale non irrilevante di utenti usano la stessa password per più servizi.
Tra l'altro moltissimi siti (e parlo di hosting) che usano plesk o cpanel hanno i certificati scaduti.

Sugli aggiornamenti, per aggiornare i programmi installati ci son varie utility che fanno la verifica anche in windows, non le cito per non fare pubblicità.
@il lupo della luna
Non sono assolutamente contro gli aggiornamenti. Ma ad esempio tra un software con 100 bug, di cui tutti e 100 coperti velocemente con aggiornamenti e uno con 10 bug e 10 aggiornamenti.. ritengo che il secondo sia stato sviluppato meglio.
Che le probabilità di trovare gli errori in produzione sia la stessa mi sembra ovvio, ma io parlavo invece di tempi, di velocità nel rilasciare gli aggiornamenti, chiaramente dopo aver individuato gli errori. Mi arrendo e non aggiungo altro :-) perché mi si ribatte solo su cose che non scrivo, tralasciando invece i commenti reali che ho fatto.

Per le BSD ti confermo che interessa: FreeBSD 10.0, OpenBSD 5.3 e 5.4 e netBSD 5.02... le altre versioni da quanto leggo nei vari forum dovrebbero essere ok.