Olimpo Informatico

[Zeus News]

Leggi l'articolo Come difendersi da Heartbleed
La falla di sicurezza senza precedenti che ferma Internet.


 
Sai che una falla è grave quando ha un logo tutto suo.
 

Segnala un refuso

[spacexplorer]

Tre piccole note: il baco (errore) non consente di acquisire esplicitamente
a colpo sicuro dati personali critici (mail, password ecc), il baco consente
di leggere da remoto la ram del processo OpenSSL ovvero può consentire di
esporre dati sensibili tra cui utenti, password, ecc ora il dump della ram
di un processo da remoto è affare MOLTO grave ed è ancora più grave l'estrema
difficoltà di trovare tracce (non impossibilità) ma non è come avere una shell
e poter andare a ficcanasare in giro, questo per tranquillizzare un po' gli
animi

Altra cosa: il baco è stato corretto PRIMA della sua pubblicazione come
avviene di solito in ambiente *nix dove gli sviluppatori (indipendenti e/o
volontari e/o pagati da qualche azienda) vengono contattati direttamente in
privato dai ricercatori/hacker che scoprono una vulnerabilità e provvedono
a correggerla subito (a differenza di cert'une blasonate aziende). Il problema
è che non tutti gli utenti del progetto OpenSSL sono veloci quanto le varie
distribuzioni ad aggiornare...

In genere vulnerabilità GRAVI/critiche ovvero usabili da remoto per accedere
ad un sistema si scoprono in ragione di una ogni 10 anni, contro le scoperte
quasi giornaliere che avvengono in ambito Microsoft od Apple, la maggior
parte delle vulnerabilità scoperte sono POTENZIALI, non sfruttabili da remoto
e corrette immediatamente senza aspettare che qualcuno dimostri come poterle
sfruttare. L'eco sulla stampa dimostra QUANTO sia realmente diffuso il software
opensource, giusto per tacitare chi dice "GNU / Linux lo usano i geek in
garage e basta" (son sempre meno ma ancora tanti ci sono...).

Lato utente se si hanno installare le OpenSSL (ovvero quasi sempre) c'è da
aggiornare lo stesso e in ambito *nix questo è una prassi normale e spesso
del tutto automatica, non credo che vi siano utenti GNU / Linux che ancora
non abbiano aggiornato. Sono invece ragionevolmente certo che ci siano
tonnellate di router ADSL domestici, di servizi vari sparsi per l'web e di
applicazioni Windows (che in genere si portano dietro le librerie anziché
linkarle dall'OS come avviene di norma in ambito *nix), stampanti di rete
ecc che non solo non sono aggiornati ma che non lo saranno per un pezzo,
forse per tutta la loro vita operativa. Il problema è tanto sentito che vi
sono iniziative non proprio di piccoli (Google e Facebook tanto per citare
qualche piccolino) che vogliono IMPORRE l'open-platform su ogni dispositivo.
Il brutto è che prima di arrivare all'utente finale ci vogliono anni e molti
utenti finali pensano che lo scatolino chiuso anziché un problema sia una
garanzia di sicurezza...

Vorrei giusto a tema tirare le orecchie a tanti colleghi che non gradiscono
pensare le infrastrutture che gestiscono (ma anche il loro laptop personale)
come qualcosa che evolve ed anzi vivono ogni novità come il mal di denti!

[{34567890}]

OpenSSL: vulnerabilità e raccomandazioni

Un difetto in una delle più importanti biblioteche di crittografia ( OpenSSL ) che identifica innumerevoli utenti di Internet. Grazie a questa vulnerabilità , un utente malintenzionato può leggere parte della memoria di un server per un attimo, che contiene i dati trasmessi dall'utente . Si possono leggere le passwords, dati transazionali ma anche i dati dal server ( come chiavi private ) . Fornitori di messaggistica od istituti finanziari non sono i soli ad essere interessati, ma anche altri portali Web ( e-commerce, assicurazione sanitaria, ecc. ) Che offrono una connessione crittografata, utilizzando il software vulnerabile . Tuttavia, altri servizi che non sono browser-based, possono essere colpiti : Apps per gli smartphones, servizi di chat ( ad esempio Jabber ), cloud storage , servizi di streaming ( streaming), i servizi di messaggistica, accesso VPN, ecc .

MELANI è in contatto con le aziende di telecomunicazioni, istituzioni finanziarie e altre aziende che operano infrastrutture critiche. Molte aziende hanno già installato le patch di sicurezza disponibili o sono in procinto di farlo.

MELANI formula raccomandazioni per i fornitori di servizi ed i seguenti utilizzatori finali .

Raccomandazioni per i Service Providers

Vi rimandiamo alle pubblicazioni pertinenti, tra cui :

* Heartbleed : link
* Il blog Fox- IT :
link

* Vulnerabilità OpenSSL : link

OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

Sono interessati gli utenti delle biblioteche OpenSSL 1.0.1 e 1.0.2beta. Tutti i servizi che utilizzano queste versioni sono vulnerabili (non solo web server ). Le versioni precedenti non sembrano essere colpite. Non dimenticate i servers che utilizzano o forniscono i seguenti servizi : applicazioni per gli smartphone, le chats ( Jabber ) , cloud storage, in streaming ( ad esempio Plex ), servizi di messaggistica (quali SMTP, POP, IMAP su SSL ), accesso OpenVPN, a condizione di utilizzare le librerie OpenSSL . Allo stesso modo, i dispositivi di rete, che forniscono un'interfaccia web, sono coinvolti anche, come routers e switchs . OpenSSL 1.0.1g è la prima versione in cui l'errore è stato corretto .

Raccomandazione MELANI

MELANI consiglia urgentemente per rendere l'aggiornamento corrispondente nelle prossime 24-48 ore e sostituire certificati e servizi dati sensibili di accesso . Per i servizi, le esigenze di riservatezza ed integrità sono superiori ai requisiti di disponibilità, un'interruzione temporanea del servizio possa essere giustificata. Tra le conseguenze di un attacco, dobbiamo presumere che i dati di accesso sono stati compromessi .

Una soluzione possibile è quella di riorientare gran parte del traffico di rete per i sistemi centrali di accesso (sistemi di accesso), che sono già stati aggiornati . Poi aggiornare altri sistemi gradualmente, vedere di inserire i sistemi in modo permanente non aggiornabili dietro questi sistemi di accesso .

Quando si installano i nuovi aggiornamenti, la cura deve essere presa per utilizzare solo algoritmi sicuri. In particolare, occorre prestare attenzione a sostenere Perfect Forward Secrecy 1^* .

1^* link

Inoltre , è necessario utilizzare le firme IDS e bloccare gli indirizzi IP degli attacchi.

Raccomandazioni per gli utenti finali

Per l'utente finale, è molto difficile proteggersi, a meno che non rinuncia operazioni sensibili su Internet finché i rispettivi fornitori di servizi hanno risolto il problema. Non è chiaro per quanto tempo il bug verrà sfruttato . Poiché non si può escludere che i dati sono stati violati nelle ultime settimane, MELANI consiglia per l'utente finale :

* Una volta che i fornitori hanno eliminato l'errore : cambiare tutte le passwords che sono stati utilizzati (web, messaggistica, servizi cloud , VPN, ... ) . Usare parole diverse password per ogni servizio .

Inoltre,

* Eseguire, se necessario, aggiornamenti sui dispositivi di sicurezza private, come routers e dispositivi NAS, non appena saranno disponibili .

possibili conseguenze

Un utente malintenzionato deve essere in grado di leggere abbastanza blocchi di 64 KB di memoria, al fine di costruire un attacco. E ' piuttosto difficile accedere a tutte le transazioni e tutti i dati, tuttavia, è possibile che le informazioni permettano di accedere ai dati chiave e cadere nelle mani dell'aggressore, ed utilizzi queste informazioni in seguito. No Perfect Forward Secrecy , un utente malintenzionato può decifrare poi il traffico registrato.

Ultimo aggiornamento : 2014/04/09

[milux]

premetto che per me la materia SSL è molto ostica ma leggendo l'articolo trovo :

" Le cose da fare, invece, sono queste:
- Controllate se i siti che visitate sono vulnerabili o si sono aggiornati, immettendone il nome in link oppure link. "

Provo con ssllabs.com il sito postemobile.it e il risultato è un grado F; ma sappiamo che il tutto gira su dei windows server e quindi ritengo che il risultato sia attendibile.

Poi invece su filippo.io succede esattamente l'opposto e il risultato è in una frase : All good, www.postemobile.it seems fixed or unaffected!

quindi alla fine siamo sicuri al 50%?

cmq grazie a spacexplorer pe la spiegazione molto interessante..

Per quanto mi riguarda sono windowswisizzato/h24 e debianizzato/h24 : per il primo non mi sembra di aver visto nessun aggiornamento, per il secondo l'aggiornamento è già arrivato alcuni giorni fa..

[spacexplorer]

@{34567890}
Scusa ma il tuo post cosa vorrebbe dire? A parte la traduzione di "biblioteche
SSL" che fa sorridere: "SSL libraries" si traduce in "librerie SSL" poiché in
italiano quei "software" destinati ad essere inglobati in altri anziché usati
direttamente tramite un'interfaccia si chiamano librerie, non sono le Libraries
locali commerciali un po' come silicon non è silicone ma silicio

@milux
Se solo vai su Netcraft e cerchi i vari servizi web delle Poste trovi non solo
tanti sistemi diversi ma anche tanti cambi avanti e indietro (un anno usano X
poi passano ad Y poi tornato ad X ecc). IMO, a ben guardare vedo che quasi
tutta l'infrastruttura IP critica è sempre stata su soluzioni SUN (Solaris) con
un po' di Microsoft (ipotizzo per far contento qualche commerciale) su servizi
meno critici/non considerati core-business ed in tempi recenti c'è stato un
passaggio verso F5 (per lo più GNU / Linux ma è difficile da dire) ovvero
ipotizzo la ricerca di un nuovo mono-vendor per la propria infrastruttura che
sia commercialmente più vicino a SUN che ad Oracle (non so se F5
commercialmente e tecnicamente si possa considerare tale cmq...).

Questo unito alla "fama" delle Poste mi fa pensare che nel complesso la
struttura "critica" sia pensata da gente competente ma l'insieme sia talmente
burocratizzato, sparso e a comparti stagni da essere ben poco efficiente di
fatto.

Per così dire, si sicurezza al 50% è una definizione calzante e per me ciò
implica il cartello "evitare a priori"

Per chi non vuol scomodarsi a fare una ricerca, i link sono tutti a
Netcraft con i dati dei relativi siti, da Netcraft cliccate sul "Site"
corrispondente per visitare il sito, cliccate sul "Site Report" per avere
dettagli e storico:
* *.poste.it vedete i singoli sotto-domini
* Corriere SDA
* Postel.it (gestione documentale, posta telematica ecc)
* Postecom.it (il cuore informatico delle Poste)
* Postevita/Poste Assicura
* Bancoposta SGR
* Poste Shop
* PosteMobile
* Mistral Air
* Banca del Mezzogiorno/MedioCredito Centrale

[{34567890}]

a notte fonda, leggendo la notizia, ed avendo appreso che era disponibile in Francese od in Tedesco, ho cercato di fare la miglior traduzione possibile, affinchè tutti possano sapere di cosa si tratta.

[elisam]

scusate ma comincio a entrare in confusione (o forse lo sono sempre): dalle varie descrizioni il problema consiste nella possibilita' di 'rubare' la chiave privata (quella accoppiata alla chiave pubblica che viene rilasciata agli utenti) dai server OpenSSL.Quindi a rigor di logica all'utente e' sufficiente cambiare le sue password dal momento che il server viene aggiornato, e non prima. E non aggiornare il computer per questo problema

[MaXXX eternal tiare]

Da quello che ho capito aggiornare sui propri pc le librerie openssl se ci sono fa in modo che noi (clinet) nn si possa essere vittime degli attacchi (ho capito bene Spacexplorer?) ma finche i siti nn aggiornano siamo cmq vulnerabili e quindi dopo che hanno aggiornato va cambiata la password nostra.

cmq sembrano molto veloci nel farlo almeno i siti grossi sembrano apposto.

[elisam]

se lo si vuol fare non e' mal fatto ma non credo proprio sia obbligatorio aggiornare le librerie OpenSSL, i disgraziati utenti Windows, MAC, Android vari, iOS, etc (escludendo Linux ovviamente) cosa dovrebbero fare ? aspettare gli update dai loro fornitori di OS? oppure andarsi a cercare le librerie buone su internet e installarsele? fate voi

[spacexplorer]

@{34567890}
Oki, grazie ora ho capito

@elisam, @MaXXX eternal tiare
non prendetevela se la faccio lunga la sintesi non è il mio forte un
server inteso come software è un'applicazione che quando funziona ascolta su
una porta in attesa che qualcuno lo contatti. Se questo "server" ("servizio" in
ambiente Microsoft, "demone" in ambiente *nix) usa OpenSSL in una versione
vulnerabile è "attaccabile".

Ora sui computer personali in genere non ci sono siti web, server di posta ecc
però c'è spesso qualche applicazione server, ad esempio avete una "directory
condivisa"? Questa altro non è che un programam che rende disponibile l'accesso
ad una certa directory ed eventuali sottodirectory ad altri computer in rete
(in genere rete locale), questo è un fileserver, usa OpenSSL in una versione
vulnerabile? Allora è vulnerabile. Avete un softphone VoIP (Skype, Jitsi,
SFLPhone, Zoiper, ...)? Questo spesso supporta le chiamate IP2IP ovvero offre
un servizio "voce" a chi si collega direttamente a lui ecc ecc.
Se usate Windows potete vedere quali "server" avete in funzione ad es. con
TCPView è un freeware di Microsoft/Sysinternals, potete anche farlo senza
installare nulla da un terminale (cmd.exe, cercandolo dal menù start o come si
chiama di questi tempi) digitando: netstat -a -b -n su GNU/Linux ci sono vari modi,
ad es. netstat -tunplw

Su GNU / Linux ed in ambiente *nix in genere (eccetto OSX tanto per cambiare)
il software si intalla da repository ovvero l'intallazzione ed aggiornamento
sono automatizzati, in ambiente Microsoft ed Apple è così solo in parte, la
maggior parte del software in questi ambienti è distribuito su CDrom o fatto
scaricare a mano da qualche sito e questo implica ad esempio che dobbiate non
"aggiornare e basta" ma "andare a cercare chi usa le librerie OpenSSL e vedere
se il suo produttore ha rilasciato un aggiornamento e andarvelo ad installare"

Secondo punto: qual'è la minaccia? Bé c'è un'ottima (come al solito) vignetta
di Xkcd che spiega la cosa. In parole l'attaccante può farsi dare dal
server sino a 64Kb di memoria ram allocata dal processo SSL nei dintorni della
sua richiesta, ovvero NON PUÒ andarsi a leggere ciò che c'è sull'hard disk,
leggere memoria di altri processi ecc. Il brutto della cosa è che OpenSSL è
nato per proteggere informazioni quindi ciò che si trova nella sua ram è
potenzialmente roba che non si vuole rendere pubblica, per esempio ANCHE nomi
utenti/password DI ALCUNI UTENTI CHI SI STANNO LOGGANDO sul servizio sotto SSL
DURANTE l'attacco. Anche potenzialmente chiavi private, certificati d'origine
ecc. Il baco è in giro da circa due anni quindi un attaccante paziente può
anche aver preso parecchi pezzi da 64Kb e esser andato a caccia di roba
interessante (password ecc) in essi, tale attaccante deve ovviamente
essersi accorto della vulnerabilità prima del resto del mondo, cosa difficile
per software opensource con vasta audience... 'Somma per la sicurezza
informatica e per il mondo opensource/professionale è una grave falla ed ogni
cosa potenzilamente affetta va considerata COMPLETAMENTE compromessa, per chi
usa tutti i giorni sistemi operativi dovo scoprono la possibilità di accedere
da remoto a livelli addirittura amministrativi ogni pochi giorni...

Diciamo che la notizia ha fatto il giro della stampa perché vulnerabilità
sfruttabili da remoto in software opensource sono casi molto rari e questa
tipologia di software è usata sopratutto su sistemi che si vuole siano sicuri
ed è stata ideata per rendere sicuri dei servizi.

Quindi @elisam in genere si può star tranquilli che non è crollato il mondo e
i disgraziati utenti Windows, OSX, Android, iOS ecc non possono far altro che
aspettare l'update dei loro fornitori, non possono cercarsi le librerie buone
da loro poiché i programmi che queste librerie usano sono in genere chiusi,
non c'è modo di dirgli "usa queste librerie". Questo è l'ennesima dimostrazione
dei problemi del software closed-source. Ah, non solo gli utenti OSX/Windows&c
anche i router domestici, le smarttv ecc possono essere vulnerabili e anche
se queste si basano su codice opensource e quindi i produttori sono costretti
a rilasciare il codice non è detto che questi abbiano previsto alcun sistema
di aggiornamento usabile. In vari casi devi aprire fisicamente la macchina e
saldarci sopra qualche cavo per poter aggiornare qualcosa!

La morale? Non usate software chiuso, non accettate roba di produttori che
lavorano legando hw&sw!

Ps per chi vuole un'analisi tecnica come si deve: qui c'è un ottimo post a tema,
codice alla mano.

[MaXXX eternal tiare]

Grazie Spaceexplorer molto esauriente

[elisam]

@spacexplorer
certo che e' che cosi', solo che dal tuo post precedente mica era chiaro

[mda]

Per assurdo chi non aveva aggiornato nel 2011 (sono tanti) è al sicuro.

[elisam]

come si fa?
sono giorni e post in questa discussione e altre che si dice che devono essere aggiornati i server OpenSSL ( i web server ) e non gli smartphone o i pc. Su questi si cambieranno le password solo dopo che il server e' stato aggiornato, altrimenti non servirebbe in quando la vostra password per quel sito potrebbe gia' essere stata decriptata. Se cercate su internet potete trovare link che permettono di verificare gratuitamente se un dato sito ha risolto il problema.

[jumpjack]

Quindi chi negli ultimi due anni sapeva del bug e ha passato il tempo a scandagliare IP in giro per il mondo, adesso potrebbe avere le password di accesso di qualunque router privato collegato a una webcam, per esempio?

[spacexplorer]

@elisam
Tieni presente che oltre alla scarsa probabilità di ricavare informazioni
utili le password se il sito non è fatto coi piedi non vengono inviate in
chiaro, viene inviato il loro hash. Per farti un'idea se hai una distro
GNU / Linux od un OSX per le mani (o installi cygwin su Windows) dai da una
shell (Terminal.app in OSX):

[jumpjack]

@spacexplore ma che dici ???
Qui non parliamo di dati TRASMESSI, ma di dati presenti in RAM! Se in quel momento in RAM ci sono le hash appena lette da disco, o peggio le pwd in chiaro,....

[elisam]

Scusa Spacexplorer ma sono un po dura di comprendonio: e' ultra-assodato a livello universale che Heartbleed e' un problema di server e quindi non si devono attendere aggiornamenti specifici per i client : gli utenti. I CLIENT AL MASSIMO DEVONO CAMBIARE LE PASSWORD
Non mi sembra questo il caso giusto per propugnare la bonta' e l'affidabilita' dell' open source, cosa su cui sono invece d'accordo per altri motivi.
Su Wired inoltre c'e' un interessante articolo su nomi e cognomi dei programmatori del baco e sulle condizioni in cui e' successo, credo meriti un po' di riflessione

[{umby}]

Aggiungo una precisazione che fin'ora nessuno ha espresso.
Il baco é nato dall'aggiunta di una funzione nel software openssl due anni fa.
Tutto ció che non ha subito aggiornamenti in questi due anni, non ha il baco.
Per contro, fare attenzione che acquistando apparecchiature nuove (ovvio che mi riferisco ad oggetti in cui sono usate le openssl), si corre il rischio di poprtarsi a casa un coso vulnerabile. In tal caso, prima dell'acquisto, assicurarsi che ci sia l'aggiornamente scaricabile.

[spacexplorer]

@jumpjack
Se un sistema è ben fatto non ha password in chiaro, non gli servono. Salva
solo gli hash salt-ati ed il salt, altra cosa da far rilevare a coloro che
insistono nel salvare password in chiaro da qualche parte :->

Se nel "momento dell'attacco" nei massimo 64Kb che vengono letti c'è proprio
l'hash della tua password e il tuo nome utente e il sito non usa altro per
autenticarti (ad es. le chiavette tipicamente usate dalle banche di cui ai
post precedenti) si, facendosi un client in casa può autenticarsi come se
fossi tu. Per andar sul negativo l'attaccante può persistere nell'attacco
con frequenze anche abbastanza alte (se ha una botnet/tanti proxy od altro
ed il sito attaccato ha un bel traffico è difficile che si noti qualcosa di
strano) e quindi aumentare di parecchio le chances di beccare qualcosa di
utile.

Non è certo una bella cosa MA in genere siti che gestiscono cose critiche come
ad esempio le banche usano altre cose oltre ad user&password, i token/otp che
siano chiavette, codici inviati via sms, codici prestampati ecc sono un buon
esempio. In questo caso anche se l'ipotetico attaccante ha user&password non
può far nulla. E ancora in genere anche se qualcuno prende il tuo posto e fa
qualcosa in tuo nome se questo qualcosa è importante ci sono salvaguardie
extra, ad esempio sempre nel settore banche in molti casi non sono permessi
bonifici sopra un certo importo dal solo canale web, secondo cosa fai hai
l'avviso via sms, se proprio ti han fregato e si scopre la causa/dimostri che
non potevi essere tu ci sono le assicurazioni ecc.

Il discorso sullo sniffing era relativo alle telecamere IP/DVR domestici che
in genere se offrono un accesso via internet non lo fanno con un'autenticazione
sotto SSL ma totalmente in chiaro

In generale essere interconnessi/informatizzati porta enormi benefici e con
questi crescono anche alcune responsabilità, è triste che si scopra tanta
gente preoccupata in casi come questo quando poi se parli di aggiornamenti
regolari ti guardano storto, se parli di non scrivere password in mail/sms
o peggio su qualche post-it o sceglierne di idiote ecc ti guardano storto...
È ancor più triste notare come qualcuno punti il dito contro il giovane
programmatore che ha commesso l'errore e contro l'opensource quando in codici
chiusi venduti a caro prezzo di vulnerabilità ben più gravi se ne scoprono
ogni giorno e chi oggi si straccia le vesti per questo baco in genere se ne
infischia (frasi tipo "io windows non l'ho mai aggiornato" ecc). Se valuti la
cosa con occhi obiettivi le probabilità che qualcuno abbia scoperto quel baco
PRIMA dei ricercatori sono minime, in più chi come il mondo open è veloce ad
aggiornare è stato realmente scoperto per poco tempo, in genere non più di
mezz'ora, un'ora per un server mentre chi usa roba proprietaria potrebbe anche
restare scoperto per tutta la vita operativa di un dato apparato come chi non
ha un'infrastruttura pensata per evolvere (provisoning automatico ecc)...

@elisam
Non mi pare così ultra-assodato: ad es Il Sole 24 ore - Il bug Heartbleed colpisce
anche le app. Il rimedio? Non usarle già, tali app non sono opensource o cmq
Android ha un package manager a dir poco infantile se paragonato ad apt&c nati
DECENNI prima e da DECENNI in uso su server, desktop ecc nel mondo... Ad ogni
modo come scritto sopra il baco riguarda qualsiasi APPLICAZIONE che offra un
servizio protetto da una versione vulnerabile di OpenSSL (server nel senso di
servizio, non macchina fisica) quindi se sul tuo computer o smartphone hai
applicazioni che offrono un servizio ed usano una versione OpenSSL vulnerabile
è bene che le aggiorni. Queste possono essere ad esempio fileserver, softphone
VoIP, programmi di condivisione contenuti multimediali (musica/video),
programmi che offrono un servizio ntp, software di assistenza remota, ...

In genere i servizi su un desktop sono solo per la rete locale quindi se non
sono nat-ati (IPv4) o non hai un ip pubblico (IPv4&v6) il rischio è minimo e
data la natura del bug anche se lo sono è bassisimo comunque.

Purtroppo in ambienti privi di package manager e librerie condivise (Windows ed
OSX ad esempio) questa caccia e aggiornamento non la fa l'OS per te, la devi
fare a mano. Per il resto IMO il consiglio è aspettare, se i servizi web che
usi sono gestiti da persone serie queste han già provveduto dal 4 aprile ad
aggiornare e se il loro schema di autenticazione era vulnerabile sarà loro
cura chiederti di impostare una nuova password al primo login che farai.

@{umby}
No, chi per due anni non ha aggiornato non è affetto da questo baco, magari in
compenso ne ha altri n molto più seri...