Heartbleed influenza i tasti ssh?

40

Il recente bug Heartbleed influenza i tasti ssh che ho generato e che uso per spingere / estrarre il codice con Github, Heroku e altri siti simili?

Devo sostituire le chiavi che ho usato?

ssh openssl heartbleed

— LikeMaBell
fonte

47

No, Heartbleed non influisce davvero sulle chiavi SSH, quindi probabilmente non è necessario sostituire le chiavi SSH che hai utilizzato.

Innanzitutto, SSL e SSH sono due protocolli di sicurezza diversi per due usi diversi. Allo stesso modo, OpenSSL e OpenSSH sono anche due pacchetti software completamente diversi, nonostante le somiglianze nei loro nomi.

In secondo luogo, l'exploit Heartbleed fa sì che il peer vulnerabile OpenSSL TLS / DTLS restituisca una memoria casuale di 64 kB, ma è quasi certamente limitato alla memoria accessibile a quel processo che utilizza OpenSSL. Se quel processo che utilizza OpenSSL non ha accesso alla tua chiave privata SSH, allora non può perdere attraverso Heartbleed.

Inoltre, in genere metti la tua chiave pubblica SSH solo sui server a cui usi SSH per collegarti e, come suggerisce il nome, una chiave pubblica è una chiave che puoi pubblicizzare. Non importa chi lo sa. In effetti, vuoi che il pubblico conosca la tua chiave pubblica corretta.

Grazie a @Bob per aver sottolineato che la vulnerabilità può influire sulle app client che utilizzano versioni vulnerabili di OpenSSL come libreria TLS / DTLS sul lato client. Pertanto, se, ad esempio, il browser Web o il client VPN basato su SSL utilizzava una versione vulnerabile di OpenSSL e si connetteva a un server dannoso, quel server dannoso poteva utilizzare Heartbleed per visualizzare frammenti casuali della memoria del software client. Se l'app client per qualche motivo avesse una copia delle tue chiavi private SSH in memoria, allora potrebbe fuoriuscire tramite Heartbleed.

Al di fuori della mia testa, non sto pensando a nessun software oltre a SSH che possa avere una copia della tua chiave privata SSH non crittografata in memoria. Bene, questo presuppone che tu mantenga le tue chiavi private SSH crittografate sul disco. Se non conservi le tue chiavi private SSH crittografate su disco, suppongo che avresti potuto usare un programma di trasferimento o backup di file utilizzando OpenSSL TLS per copiare o eseguire il backup della tua directory home sulla rete (inclusa la tua ~/.ssh/id_rsao altre chiavi private SSH ), potrebbe contenere una copia non crittografata della chiave privata SSH in memoria. Inoltre, se esegui il backup della tua chiave privata SSH non crittografata su un server dannoso, probabilmente avrai maggiori preoccupazioni rispetto a Heartbleed. :-)

— spiff
fonte

3

Si noti che il commento pubblico è davvero irrilevante: Heartbleed influenza sia i client che i server. Ma hai ragione nel dire che SSH è diverso e non è interessato da questa particolare vulnerabilità .

— Bob,

1

@Bob Grazie, gli scritti di Heartbleed sono stati così focalizzati sul server che non avevo realizzato le ramificazioni sul lato client. Ho aggiornato la mia risposta per affrontarlo meglio. Continuo a pensare che è molto improbabile che le persone abbiano lasciato una chiave privata SSH da qualche parte che un processo vulnerabile Heartbleed potrebbe essere in grado di trapelare.

— Spiff

1

Si dovrebbe menzionare che SSH utilizza la libreria OpenSSL per la crittografia. Come hai sottolineato, tuttavia, ssh non è influenzato dall'exploit dal cuore perché è un protocollo diverso.

— psibar,

1

"In secondo luogo, l'exploit Heartbleed fa sì che il peer vulnerabile OpenSSL TLS / DTLS restituisca una memoria casuale di 64 kB, ma è quasi certamente limitato alla memoria accessibile a quel processo che utilizza OpenSSL."

se la macchina viene compromessa, come puoi fidarti di qualcosa, incluso ssh? da heartbleed.com

"Cosa perde in pratica?

Abbiamo testato alcuni dei nostri servizi dal punto di vista dell'attaccante. Ci siamo attaccati dall'esterno, senza lasciare traccia. Senza utilizzare alcuna informazione o credenziale privilegiata siamo stati in grado di rubare a noi stessi le chiavi segrete utilizzate per i nostri certificati X.509, nomi utente e password, messaggi istantanei, e-mail e documenti e comunicazioni aziendali critici. "

qualcuno avrebbe potuto mettere una chiave privata, senza passphrase, su un server che ritenevano non fosse malevolo ... ma si rivelò essere. b / c bug SSL consentiva la password di un utente, un utente che aveva "sudo" ... probabilmente non è un problema .... ma ...

la gente fa cose pazze a volte

http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/

— don luminoso
fonte

Penso che la citazione si riferisca a un uomo nell'attacco centrale usando le chiavi TLS rubate. Un utente malintenzionato non dovrebbe essere in grado di accedere alla memoria da altri programmi, altrimenti ciò evidenzia un problema di sicurezza nel sistema operativo.

— Matthew Mitchell,

Se un utente ha inserito la sua chiave SSH privata non crittografata sui server, allora è al di là del nostro aiuto. Inviagli un link a piv.pivpiv.dk .

— Spiff