Quindi ricevo informazioni contrastanti dai membri del mio team. La premessa è, se un utente malintenzionato può continuare a richiedere 64 kb di memoria dal mio server, potrebbe ottenere l'intero ingombro di memoria del mio server, e quindi ottenere la chiave privata che ho usato fuori dalla memoria.
Quindi, la chiave SSH privata che ho usato per accedere è stata memorizzata? Devo preoccuparmi delle mie chiavi SSH?
No. OpenSSH utilizza un sottoinsieme molto limitato della libreria OpenSSL e tale sottoinsieme non include il codice coinvolto nella vulnerabilità Heartbleed (o qualsiasi altro codice SSL / TLS, per quella materia).
Inoltre, la vulnerabilità Heartbleed non consente a un'applicazione di leggere la memoria al di fuori del suo spazio indirizzo, quindi, ad esempio, un server Web vulnerabile non può raggiungere e prendere le chiavi da un server SSH.
Non può essere ripetuto abbastanza: -)
No Ma! Se esegui altri servizi sul computer host, ad esempio OpenVPN , che utilizza OpenSSL, è vulnerabile e può essere sfruttato.
Quando si accede con SSH, il client ha la chiave privata e il server ha la chiave pubblica. Pertanto, nessuna vulnerabilità sul server può perdere la tua chiave privata, poiché il server non ce l'ha.
Il server non può utilizzare Heartbleed per ottenere la chiave privata dal client, poiché si tratta di un'implementazione SSH e solo le connessioni SSL / TLS OpenSSL dalla versione 1.0.1 alla 1.0.1f sono vulnerabili. Nessun'altra implementazione di alcun tipo ha questo problema, incluse tutte le implementazioni di SSH.
Ora, se il server ha le proprie chiavi SSH private in memoria da qualche parte, allora sarebbe necessaria un'indagine più approfondita .... ma sarebbe più economico riparare la vulnerabilità e quindi rigenerare la coppia di chiavi SSH del server, poiché non c'è Autorità di certificazione per pagare per firmare le chiavi SSH!
Generalmente no, ma dipende da come sei paranoico e dalle specifiche del sistema vulnerabile.
Come altri hanno già detto, le chiavi di openssh non possono essere trapelate direttamente da un server openssl che sanguina. Ma se le informazioni sono trapelate (come per esempio un login utente https) allora forse un utente malintenzionato potrebbe usare quella password per ottenere l'accesso al sistema. Da lì, la chiave privata ssh dell'utente è sicura se non si trova nel file system locale. Ma se l'attaccante usa queste informazioni per ottenere l'accesso alla radice, si verificano molti più problemi (ovviamente). Ad esempio, ora possono decodificare il traffico ssh e se sul sistema è stato abilitato un agente ssh, l'utente malintenzionato potrebbe ora eseguire ssh su altri sistemi come te, ma non ripristinare la chiave privata originale se non si trova su quel sistema.
Leggi altre domande sui tag ssh openssl heartbleed