Devo sostituire le chiavi per OpenSSH in risposta a Heartbleed?


9

Ho già aggiornato i miei server con le patch.

Devo rigenerare eventuali chiavi private rispetto a OpenSSH? So che devo rigenerare tutti i certificati SSL.

EDIT: non l'ho detto abbastanza accuratamente. So che la vulnerabilità si trova in openssl, ma mi chiedevo come questo influisce su openssh e se devo rigenerare le chiavi host di openssh.


1
In realtà questo è probabilmente un duplicato di serverfault.com/questions/587329/…
faker

Il tuo primo e terzo paragrafo sembrano contraddittori.
un CVn

@faker Non proprio - quella domanda non affronta nulla su SSH ...
voretaq7

Risposte:


5

La vulnerabilità non influisce openssh, influisce openssl.
Che è una libreria utilizzata da molti servizi, incluso openssh.

A questo punto sembra chiaro che opensshnon sia interessato da questa vulnerabilità, perché OpenSSH utilizza il protocollo SSH, non il protocollo TLS vulnerabile. È improbabile che la tua chiave privata ssh sia in memoria e leggibile da un processo che è vulnerabile - non impossibile ma improbabile.

Ovviamente devi comunque aggiornare la tua opensslversione.
Se hai aggiornato, openssldevi anche riavviare tutti i servizi che lo utilizzano.
Ciò include software come server VPN, server Web, server di posta, bilanciamento del carico, ...


1
Qualcosa da tenere a mente: è possibile utilizzare la stessa parte della chiave privata per una chiave privata SSH e un certificato SSL. In questo caso, se la chiave del certificato SSL è stata utilizzata su un server Web vulnerabile, è necessario sostituire anche la chiave privata SSH interessata. (Perché questo sia sfruttato qualcuno dovrebbe sapere che stai facendo questo, o pensare di provarlo - è una configurazione MOLTO insolita nella mia esperienza, quindi dubito che qualcuno ci penserebbe). Detto questo, non c'è niente di sbagliato nel rigenerare la / le chiave / e privata / i SSH se vuoi - un po 'di paranoia non è una brutta cosa :-)
voretaq7

2

Quindi sembra che SSH non sia interessato:

Generalmente, sei interessato se esegui un server in cui hai generato una chiave SSL ad un certo punto. Gli utenti finali tipici non sono (direttamente) interessati. SSH non è interessato. La distribuzione dei pacchetti Ubuntu non è interessata (dipende dalle firme GPG).

Fonte: chiedi a Ubuntu: come patchare CVE-2014-0160 in OpenSSL?


1

A differenza di ciò che altri hanno detto qui Schneier dice di sì.

Fondamentalmente, un utente malintenzionato può prendere 64 KB di memoria da un server. L'attacco non lascia traccia e può essere fatto più volte per afferrare un diverso 64 KB di memoria casuale. Ciò significa che qualsiasi cosa in memoria - chiavi private SSL, chiavi utente, qualsiasi cosa - è vulnerabile. E devi presumere che sia tutto compromesso. Tutto.

Non è che ssh (qualsiasi tipo) sia stato direttamente interessato, ma che le chiavi ssh possano essere archiviate in memoria e sia possibile accedervi. Questo vale per qualsiasi altra cosa archiviata nella memoria considerata segreta.


Sembra dare una panoramica molto generale del problema con questa frase. E 'la prima volta che sento che tutta la tutta la memoria è stato esposto. Finora la mia comprensione è che solo la memoria a cui ha accesso il processo vulnerabile è esposta. Vedi anche: security.stackexchange.com/questions/55076/…
faker,

0

OpenSSH non utilizza l'estensione heartbeat, quindi OpenSSH non è interessato. Le tue chiavi dovrebbero essere sicure fintanto che nessun processo OpenSSL che utilizza il battito cardiaco le avesse in memoria, ma di solito è molto improbabile.

Quindi, se sei / devi essere un po 'paranoico, sostituiscili, altrimenti puoi dormire relativamente bene senza farlo.


SSH non utilizza OpenSSL. Grande differenza lì.
Jacob,

2
OpenSSH utilizza la parte libcrypto di OpenSSL. Ecco perché devi riavviare SSH dopo aver aggiornato OpenSSL. Ecco perché alcune persone chiedono se devono sostituire le loro chiavi SSH. Vedi la mia risposta sopra ... Qual è esattamente il tuo punto?
Denis Witt,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.