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

152

Ad oggi è stato trovato un bug in OpenSSL che influenza le versioni 1.0.1 a 1.0.1f ( incluso) e 1.0.2-beta .

Da 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 ora ?

    
posta Lucio 08.04.2014 - 00:17

6 risposte

141

Gli aggiornamenti di sicurezza sono disponibili per 12.04, 12.10, 13.10 e 14.04 vedi 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 riavviare i servizi (HTTP, SMTP, ecc.) che utilizzano la versione OpenSSL interessata, altrimenti sei ancora vulnerabile. Vedi anche Heartbleed: cos'è e cosa sono opzioni per attenuarlo? 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

Dopodiché, hai bisogno per rigenerare tutte le chiavi SSL del server , quindi valutare se le tue chiavi potrebbero essere trapelate, nel qual caso gli autori di attacchi potrebbero aver recuperato informazioni riservate dai tuoi server.

    
risposta data Florian Diesch 08.04.2014 - 00:46
71

Il bug è noto come Heartbleed .

Sono vulnerabile?

Generalmente, sei interessato se esegui un server su cui hai generato una chiave SSL per 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 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 si è eseguito un server vulnerabile esposto a Internet, considerarlo compromesso a meno che i registri non mostrino alcuna connessione dall'annuncio del 2014-04-07. (Questo presuppone che la vulnerabilità non sia stata sfruttata prima dell'annuncio.) Se il tuo server è stato esposto solo internamente, se devi cambiare le chiavi dipenderà da quali altre misure di sicurezza sono in atto.

Qual è l'impatto?

Il bug consente a qualsiasi cliente di 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 client può scaricare diverse parti della memoria in tentativi successivi.

Uno dei pezzi di dati critici che l'utente malintenzionato può essere in grado di recuperare è la chiave privata SSL del server. Con questi dati, l'utente malintenzionato può impersonare il tuo server.

Come posso recuperare su un server?

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

  2. Esegui l'upgrade del pacchetto libssl1.0.0 e assicurati che tutti i server interessati vengano riavviati.
    Puoi controllare 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 utilizzi certificati autofirmati, installalo sul tuo server.
    • In ogni caso, sposta le chiavi e i certificati obsoleti (ma non eliminali, assicurati solo che non vengano più utilizzati).
  4. Ora che hai nuove chiavi non compromesse, puoi ripristinare il server online .

  5. Revoca dei 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 connessi da un po 'di tempo 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'.) Controlla i tuoi registri e modifica 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.
    • Tutti i dati scambiati da poco prima della vulnerabilità potrebbero essere rimasti nella memoria del server e quindi potrebbero essere stati divulgati a un utente malintenzionato.
    • Se qualcuno ha registrato una vecchia connessione SSL e ha recuperato le chiavi del tuo server, ora può decodificare la sua trascrizione. (A meno che la PFS sia stata assicurata - 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 ha utilizzato una versione buggata della libreria OpenSSL per implementare il protocollo SSL.
  • Il client è connesso a un server malevolo. (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 eseguito wget per scaricare un file, non c'erano dati da perdere.)

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

Riferimenti

risposta data Gilles 08.04.2014 - 12:02
40

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

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)...

Esaminando link , viene mostrato il tipo di bug 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
...
    
risposta data crimi 08.04.2014 - 08:40
17

Se i tuoi repository apt-get non contengono alcuna versione 1.0.1g OpenSSL precompilata, quindi scarica solo le fonti dal sito web ufficiale e compila.

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 collegamento simbolico.

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

Stai bene!

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

Cfr questo post del blog .

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

    
risposta data Quentin Rousseau 08.04.2014 - 04:18
12

Per coloro che non desiderano eseguire 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 & amp; & amp; apt-get install openssl libssl1.0.0 & amp; & amp; /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 deve contenere la vulnerabilità. Accertati che sia così di nuovo andando sul sito web qui sotto e testando il tuo server web.

link

    
risposta data Adrian 08.04.2014 - 23:56
11

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.

Devi 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 (ad esempio). Quindi aggiorna: apt-get upgrade -V . Quindi, riavviare i servizi interessati.

    
risposta data Domino 08.04.2014 - 19:51

Leggi altre domande sui tag