Domanda Come patchare il bug Heartbleed (CVE-2014-0160) in OpenSSL?


Ad oggi, a bug in OpenSSL è stato trovato che influisce sulle versioni 1.0.1 attraverso 1.0.1f (incluso) e 1.0.2-beta.

Dal momento che Ubuntu 12.04, siamo tutti vulnerabili a questo bug. Per correggere questa vulnerabilità, gli utenti interessati devono eseguire l'aggiornamento a OpenSSL 1.0.1g.

Come può ogni utente interessato applicare questo aggiornamento adesso?


152
2018-04-07 22:17


origine


Hai una versione interessata di openssl? - Braiam
Ho la versione patch 1.0.1-4ubuntu5.12 e ho riavviato il servizio Apache ma filippo.io/Heartbleed test sul mio sito dice ancora che sono vulnerabile Qualche idea del perché?
@ Mat Non so cosa prova quel sito, ma forse rileva che stai usando una vecchia chiave. Poiché la chiave potrebbe essere trapelata, è necessario rigenerarla. - Gilles
Davvero non vuoi aggiornare OpenSSL alle nuove versioni all'ingrosso, è un dolore incredibile. Molto più semplice è installare semplicemente il pacchetto aggiornato che corregge il problema: ubuntu.com/usn/usn-2165-1 - sarnold
hai riavviato i tuoi servizi dopo l'aggiornamento? - Axel


risposte:


Gli aggiornamenti di sicurezza sono disponibili per 12.04, 12.10, 13.10 e 14.04 vedere Avviso di sicurezza di Ubuntu USN-2165-1.

Quindi, per prima cosa è necessario applicare gli aggiornamenti di sicurezza disponibili, ad esempio eseguendo

sudo apt-get update
sudo apt-get upgrade

dalla riga di comando.

Non dimenticare di ricomincia i servizi (HTTP, SMTP, ecc.) che utilizzano la versione OpenSSL interessata, altrimenti si è ancora vulnerabili. Guarda anche Heartbleed: che cos'è e quali sono le opzioni per mitigarlo? su Serverfault.com.

Il seguente comando mostra (dopo un aggiornamento) tutti i servizi che devono essere riavviati:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Dopo di che, devi rigenerare tutte le chiavi SSL del server, quindi valutare se le tue chiavi potrebbero essere trapelate, nel qual caso gli aggressori potrebbero aver recuperato informazioni riservate dai tuoi server.


141
2018-04-07 22:46



Non sono sicuro che funzioni su Ubuntu 12.04.4 LTS. Dopo l'aggiornamento completo, openssl version dà OpenSSL 1.0.1 14 Mar 2012. Questa non è la versione con patch, giusto? O lo sto fraintendendo? - Paul Cantrell
Cosa fare con Ubuntu 13.04? Nessun openssl aggiornato disponibile :-( - Frodik
Su Ubuntu 12.04 anche la versione fissa di OpenSSL mostra 1.0.1 14 Mar 2012. Leggere la risposta di crimi per scoprire se l'installazione include la correzione. - dan
Grazie, @ Dan! Riassumendo la risposta di @ crimi qui: se corri dpkg -l | grep ' openssl ' e tu ottieni 1.0.1-4ubuntu5.12 allora sei a posto. - Paul Cantrell
Patch e riavvio non sono sufficienti. Devi rigenerare le chiavi e valutare se le tue chiavi sono state trapelate o altro materiale riservato. Vedi per es. Heartbleed significa nuovi certificati per ogni server SSL? - Gilles


Il bug è noto come heartbleed.

Sono vulnerabile?

In genere, si è interessati se si esegue un server su cui è stata generata una chiave SSL ad un certo punto. La maggior parte degli utenti finali non è interessata (direttamente); almeno Firefox e Chrome non usano OpenSSL. SSH non è interessato. La distribuzione dei pacchetti di Ubuntu non è influenzata (si basa sulle firme GPG).

Sei vulnerabile se esegui qualsiasi tipo di server che utilizza le versioni di OpenSSL 1.0-1.0.1f (eccetto ovviamente le versioni che sono state riparate dopo la scoperta del bug). Le versioni di Ubuntu interessate sono 11,10 oneiric fino alle 14.04 pre-release fidate. È un bug di implementazione, non un difetto nel protocollo, quindi sono interessati solo i programmi che utilizzano la libreria OpenSSL. Se si ha un programma collegato alla vecchia versione 0.9.x di OpenSSL, questo non ne risente. Sono interessati solo i programmi che utilizzano la libreria OpenSSL per implementare il protocollo SSL; i programmi che utilizzano OpenSSL per altre cose non sono interessati.

Se hai eseguito un server vulnerabile esposto a Internet, consideralo compromesso a meno che i tuoi registri non mostrino alcuna connessione dall'annuncio del 2014-04-07. (Ciò presuppone che la vulnerabilità non sia stata sfruttata prima del suo annuncio.) Se il tuo server è stato esposto solo internamente, se è necessario cambiare le chiavi dipenderà da quali altre misure di sicurezza sono in atto.

Qual è l'impatto?

Il bug consente qualsiasi cliente chi può connettersi al server SSL per recuperare circa 64kB di memoria dal server. Il client non ha bisogno di essere autenticato in alcun modo. Ripetendo l'attacco, il cliente può scaricare diverse parti della memoria in tentativi successivi.

Una delle parti critiche di dati che l'utente malintenzionato può essere in grado di recuperare è la chiave privata SSL del server. Con questi dati, l'attaccante può impersonare il tuo server.

Come posso recuperare su un server?

  1. Porta offline tutti i server interessati. Finché sono in esecuzione, stanno potenzialmente perdendo dati importanti.

  2. Aggiorna il libssl1.0.0 pacchettoe assicurarsi che tutti i server interessati vengano riavviati.
    È possibile verificare se i processi interessati sono ancora in esecuzione con `` grep 'libssl.(cancellato) "/ proc // maps`

  3. Genera nuove chiavi. Questo è necessario perché il bug potrebbe aver permesso a un utente malintenzionato di ottenere la vecchia chiave privata. Segui la stessa procedura che hai usato inizialmente.

    • Se si utilizzano certificati firmati da un'autorità di certificazione, inviare le nuove chiavi pubbliche alla CA. Quando ottieni il nuovo certificato, installalo sul tuo server.
    • Se si utilizzano certificati autofirmati, installarlo sul proprio server.
    • In entrambi i casi, spostare le vecchie chiavi e i certificati fuori strada (ma non eliminarli, basta assicurarsi che non vengano più utilizzati).
  4. Ora che hai nuove chiavi senza compromessi, puoi farlo riporta il tuo server online.

  5. Revocare i vecchi certificati.

  6. Valutazione dei danni: eventuali dati che sono stati nella memoria di un processo che servono connessioni SSL potrebbero essere stati trapelati. Questo può includere password utente e altri dati riservati. È necessario valutare quali potrebbero essere stati questi dati.

    • Se stai eseguendo un servizio che consente l'autenticazione tramite password, le password degli utenti che si collegano da poco prima che la vulnerabilità fosse annunciata dovrebbero essere considerate compromesse. (Un po 'prima, perché la password potrebbe essere rimasta inutilizzata in memoria per un po' di tempo.) Controllare i registri e modificare le password di qualsiasi utente interessato.
    • Invalida anche tutti i cookie di sessione, in quanto potrebbero essere stati compromessi.
    • I certificati client non sono stati compromessi.
    • Qualsiasi dato scambiato da poco prima della vulnerabilità potrebbe essere rimasto nella memoria del server e quindi potrebbe essere stato divulgato a un utente malintenzionato.
    • Se qualcuno ha registrato una vecchia connessione SSL e ha recuperato le chiavi del tuo server, ora può decifrare la sua trascrizione. (Salvo che PFS è stato assicurato - se non lo sai, non lo era.)

Come posso recuperare su un client?

Ci sono solo poche situazioni in cui sono interessate le applicazioni client. Il problema sul lato server è che chiunque può connettersi a un server e sfruttare il bug. Per sfruttare un cliente, devono essere soddisfatte tre condizioni:

  • Il programma client utilizzava una versione buggata della libreria OpenSSL per implementare il protocollo SSL.
  • Il client è connesso a un server dannoso. (Quindi, ad esempio, se ci si è collegati a un provider di posta elettronica, questo non è un problema.) Ciò doveva accadere dopo che il proprietario del server veniva a conoscenza della vulnerabilità, quindi presumibilmente dopo il 2014-04-07.
  • Il processo client aveva dati riservati in memoria che non erano condivisi con il server. (Quindi se hai appena corso wget per scaricare un file, non c'erano dati da perdere.)

Se l'hai fatto tra il 2014-04-07 serale UTC e l'aggiornamento della tua libreria OpenSSL, considera i dati che erano nella memoria del processo client per essere compromessi.

Riferimenti


71
2018-04-08 10:02



Non credo che "solo il lato server delle connessioni SSL / TLS sia interessato" è vero. openssl.org/news/secadv_20140407.txt dice che può rivelare segreti da client o server. ubuntu.com/usn/usn-2165-1 concorda. Le probabilità che si stiano utilizzando certificati client durante la connessione a un server malevolo sono ridotte, ma esiste la possibilità. - armb
@armb Fai un buon punto. Non importa nemmeno se vengono utilizzati i certificati client, la perdita di dati non è correlata all'uso dei certificati. Io ho arruolato l'aiuto di professionisti. - Gilles
I certificati client sono il caso in cui si perderebbero le chiavi private, ma sì, le password, i cookie di autorizzazione, ecc. Potrebbero perdere comunque. Tuttavia, con un client basato su OpenSSL come curl o wget nell'uso tipico, non si avrebbero segreti per altri siti in memoria durante la connessione a un server malevolo, quindi in tal caso penso che l'unica perdita sarebbe se si fornissero i segreti del client anticipando di dar loro un sito legittimo e Heartbleed li ha fatti trapelare durante l'handshake prima che la verifica del certificato rivelasse che non sei connesso al sito giusto. - armb
@ Gilles Potresti essere interessato alle risposte Quali clienti si sono dimostrati vulnerabili a Heartbleed?. Sono riuscito ad ottenere memoria "interessante" su nginx (modalità proxy), wget, link e altri. - Lekensteyn
@ MuhamedHuseinbašić Il pacchetto openssl contiene strumenti da riga di comando. Non viene utilizzato dalle applicazioni che utilizzano la libreria OpenSSL per implementare il protocollo SSL (come Apache). Ma dovresti semplicemente applicare gli aggiornamenti di sicurezza della distribuzione. - Gilles


Per vedere quale versione di OpenSSL è installata su Ubuntu esegui:

dpkg -l | grep openssl

Se viene visualizzata la seguente versione, è necessario includere la patch per CVE-2014-0160.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Guardando https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, mostra quale tipo di bug sono corretti:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...

40
2018-04-08 06:40



Ho aggiornato e ottenuto la versione 5.12 ma questo strumento mi dice ancora che sono vulnerabile filippo.io/Heartbleed Pensieri? - toxaq
Ho testato i nostri server aggiornati su questo lato e mi ha detto che non sono interessato. Hai riavviato il sistema, o almeno sei sicuro che tutti i processi necessari sono stati riavviati? - crimi
Dopo aver aggiornato OPENSSL, tutto quello che dovevo fare era riavviare il servizio Apache, ma grazioso non ha aiutato. Dovevo andare e riavviare usando sudo service apache2 restart - Tom Hert
Ho appena scoperto la causa della mia vulnerabilità: avevo installato mod-spdy-beta. Dopo averlo rimosso e riavviato Apache, tutti i test sono ora verdi. - Andreas Roth
In aggiornamento openssl non risolve applicazioni come Apache, Nginx o Postfix. Devi aggiornare libssl1.0.0 e riavvialo come spiegato in altri post. - tnj


Se tuo repository apt-get non contiene alcun precompilato 1.0.1g OpenSSL versione, quindi basta scaricare le fonti dal sito ufficiale e compilarlo.

Sotto la singola riga di comando per compilare e installare l'ultima versione di openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Sostituisci il vecchio file binario openssl con quello nuovo tramite un link simbolico.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Sei tutto buono!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cfr. Questo post sul blog.

NB: Come affermato nel post del blog, questa soluzione non risolverà "server Nginx e Apache che devono essere ricompilati con sorgenti openSSL 1.0.1g."


17
2018-04-08 02:18



Come di solito Ubuntu non fornisce la nuova versione upstream ma ha corretto le versioni per tutte le versioni supportate per mantenere le modifiche al minimo. - Florian Diesch
Nota: assicurarsi di riavviare il server dopo aver aggiornato OpenSSL. Apache e Nginx hanno preso il nuovo lib e la vulnerabilità è stata chiusa. - dAngelov
Heh, ora che mi prendo il tempo di leggere il dettagli di questo post, sono ancora più sbalordito: scaricare un tarball da un posto casuale fuori da Internet, spacchettare ed eseguire parti di esso come root è solo un comportamento sconsiderato. Sarebbe un po 'meglio se le firme del tarball fossero scaricate e controllate, ma accertarsi di convalidare che le firme erano firmate dal tasto giusto è di per sé una domanda difficile. Le distribuzioni hanno già fatto il possibile per garantire la sicurezza della provenienza di tarball e patch. Grazie. - sarnold
potrebbe essere una buona idea compilare dal sorgente NOW, e installarne uno più recente da apt, in questo modo più sicuro che senza aspettarsi che le versioni precedenti di Ubuntu siano solo i miei due centesimi - nwgat
@sarnold openssl.org non sembra un posto a caso per scaricare il sorgente per openssl. Canonical dovrebbe renderlo non necessario, ma openssl.org dovrebbero essere l'autorevole a monte dal quale lavorare. - Rustavore


Per coloro che non vogliono fare un aggiornamento del pacchetto a livello di server. Ho letto un sacco di queste guide oggi e apt-get upgrade openssl === apt-get upgrade questo applicherà tutte le correzioni di sicurezza richieste dal tuo computer. Meraviglioso, a meno che tu non sia esplicitamente appoggiato su una vecchia versione del pacchetto da qualche parte.

Questa è l'azione minima richiesta su Ubuntu 12.04 LTS con Apache 2:

  • Vai a questo indirizzo e dimostra di avere la vulnerabilità. È necessario utilizzare l'INDIRIZZO ESTERNO DIRETTO DEL SERVER WEB. Se si utilizza un loadbalancer (ad esempio ELB), è possibile che non si stia contattando direttamente il server Web.

  • Eseguire il seguente liner 1 per aggiornare i pacchetti e riavviare. Sì, ho visto tutte le guide dire che dovresti avere un timestamp più tardi del 4 aprile 2014, questo non sembra essere il mio caso.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Assicurati di aver installato le versioni del pacchetto appropriate e controlla ancora una volta il tuo server web per la vulnerabilità.

I pacchetti chiave sono i seguenti, ho determinato queste informazioni utilizzando il comando seguente e poi ho eliminato il cruft (non è necessario sapere molto sullo stato delle mie macchine).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 NON dovrebbe contenere la vulnerabilità. Accertati che sia così di nuovo andando sul sito web qui sotto e testando il tuo server web.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



L'utilizzo di un sito esterno per dimostrare una vulnerabilità in un server sembra essere l'approccio sbagliato per me. - Rinzwind
Gli script di test di vulnerabilità esterni stanno diventando sempre più comuni in questi giorni. Fa esattamente ciò che fa uno script interno, la connessione è appena iniziata da un server web esterno. Puoi guardare siti come WhiteHatSecurity.com per un esempio di un programma che avvia tutte le connessioni da remoto. Ci sono casi in cui questo non sarebbe possibile, ad esempio test di vulnerabilità della rete, ma per testare un server web rivolto in avanti (che in generale sarà un server SSL) è quasi l'ideale. - Adrian
Perché installare il pacchetto se è stato aggiornato? - Braiam
apt-get install openssl libssl1.0.0 lo ha fatto per me. In esecuzione openssl version -a ora mostra: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
"Gli script di test di vulnerabilità esterni stanno diventando sempre più comuni in questi giorni". Questo apre la possibilità a quel sito esterno di abusare del mio sistema: tutto quello che hanno bisogno di sapere che fallisce e hackerare il mio sistema prima che lo patch. No questo non è il modo corretto. (e sì, ospita i miei siti personali con apache e openssl). - Rinzwind


Ho notato molti commentatori qui che hanno bisogno di aiuto con urgenza. Stanno seguendo le istruzioni e l'aggiornamento, e il riavvio, e sono ancora vulnerabili quando utilizzano alcuni dei siti Web di test.

È necessario verificare di non avere pacchetti in attesa come libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Per aggiornare quelli apt-mark unhold libssl1.0.0 (per esempio). Quindi aggiorna: apt-get upgrade -V. Quindi, riavviare i servizi interessati.


11
2018-04-08 17:51