Beeinflusst Heartbleed SSH-Schlüssel?

24318
LikeMaBell

Beeinflusst der jüngste Heartbleed-Fehler die von mir generierten SSH-Schlüssel, um Code mit Github, Heroku und anderen ähnlichen Websites zu drücken / zu ziehen?

Muss ich die verwendeten Schlüssel ersetzen?

40

2 Antworten auf die Frage

47
Spiff

Nein, Heartbleed wirkt sich nicht wirklich auf SSH-Schlüssel aus, daher müssen Sie wahrscheinlich die von Ihnen verwendeten SSH-Schlüssel nicht ersetzen.

Erstens sind SSL und SSH zwei verschiedene Sicherheitsprotokolle für zwei verschiedene Zwecke. Ebenso sind OpenSSL und OpenSSH trotz der Ähnlichkeiten in ihren Namen auch zwei völlig unterschiedliche Softwarepakete.

Zweitens bewirkt der Heartbleed-Exploit, dass der verwundbare OpenSSL TLS / DTLS-Peer zufällige 64-KB-Speicher zurückgibt. Es ist jedoch höchstwahrscheinlich auf den für diesen OpenSSL-Verwendungsprozess zugänglichen Speicher beschränkt. Wenn dieser OpenSSL-Prozess keinen Zugriff auf Ihren privaten SSH-Schlüssel hat, kann er nicht über Heartbleed auslaufen.

Außerdem legen Sie Ihren öffentlichen SSH- Schlüssel normalerweise nur auf Servern ab, zu denen Sie SSH verwenden, um eine Verbindung herzustellen. Wie der Name schon sagt, ist ein öffentlicher Schlüssel ein Schlüssel, den Sie veröffentlichen können. Es ist egal, wer es weiß. Sie möchten, dass die Öffentlichkeit Ihren richtigen öffentlichen Schlüssel kennt.

Danke an @Bob für den Hinweis, dass die Sicherheitsanfälligkeit Client-Apps betreffen kann, die verwundbare Versionen von OpenSSL als clientseitige TLS / DTLS-Bibliothek verwenden. Wenn beispielsweise Ihr Webbrowser oder Ihr SSL-basierter VPN-Client eine anfällige Version von OpenSSL verwendet und eine Verbindung zu einem böswilligen Server hergestellt hat, kann dieser böswillige Server Heartbleed verwenden, um zufällige Snippets des Speichers dieser Clientsoftware anzuzeigen. Wenn diese Client-App aus irgendeinem Grund eine Kopie Ihrer privaten SSH-Schlüssel im Speicher hatte, könnte sie über Heartbleed auslaufen.

Ich denke nicht an eine Software außer SSH, die eine Kopie Ihres unverschlüsselten privaten SSH-Schlüssels im Speicher haben könnte. Nun, das setzt voraus, dass Sie Ihre privaten SSH-Schlüssel auf der Festplatte verschlüsseln. Wenn Sie Ihre privaten SSH-Schlüssel nicht auf der Festplatte verschlüsselt lassen, könnten Sie wahrscheinlich ein OpenSSL TLS-verwendendes Dateiübertragungs- oder Sicherungsprogramm zum Kopieren oder Sichern Ihres Home-Verzeichnisses über das Netzwerk (einschließlich Ihres ~/.ssh/id_rsaoder eines anderen privaten SSH-Schlüssels) verwendet haben ), dann könnte sich eine unverschlüsselte Kopie Ihres privaten SSH-Schlüssels im Speicher befinden. Wenn Sie Ihren unverschlüsselten privaten SSH-Schlüssel auf einem böswilligen Server sichern, haben Sie wahrscheinlich größere Sorgen als Heartbleed. :-)

Beachten Sie, dass der öffentliche Kommentar wirklich irrelevant ist - Heartbleed betrifft sowohl Clients als auch Server. Sie haben jedoch Recht, dass SSH anders ist (und von dieser besonderen Sicherheitsanfälligkeit nicht betroffen ist) (http://security.stackexchange.com/questions/55076/what-should-a-website-operator-do-about-the-heartbleed) -openssl-Exploit # comment87050_55076). Bob vor 10 Jahren 3
@Bob Danke, die Heartbleed-Aufzeichnungen waren so auf den Server konzentriert, dass ich die clientseitigen Auswirkungen nicht erkannt hatte. Ich habe meine Antwort aktualisiert, um das besser anzugehen. Ich glaube immer noch, dass es sehr unwahrscheinlich ist, dass die Leute einen privaten SSH-Schlüssel an einem Ort hinterlassen haben, an dem ein Heartbleed-verwundbarer Prozess möglicherweise durchläuft. Spiff vor 10 Jahren 1
Es sollte erwähnt werden, dass SSH die OpenSSL-Bibliothek zur Verschlüsselung verwendet. Wie Sie bereits erwähnt haben, ist ssh jedoch nicht von dem Heartbleed-Exploit betroffen, da es sich um ein anderes Protokoll handelt. psibar vor 10 Jahren 1
1
don bright

"Zweitens bewirkt der Heartbleed-Exploit, dass der verwundbare OpenSSL TLS / DTLS-Peer zufällige 64-KB-Speicher zurückgibt. Es ist jedoch höchstwahrscheinlich auf Speicher beschränkt, der für diesen OpenSSL-Prozess verfügbar ist."

Wenn die Maschine kompromittiert wird, wie können Sie dann irgendetwas vertrauen, einschließlich ssh? von heartbleed.com

"Welche Lecks in der Praxis?

Wir haben einige unserer eigenen Dienste aus der Sicht des Angreifers getestet. Wir haben uns von außen angegriffen, ohne eine Spur zu hinterlassen. Ohne privilegierte Informationen oder Anmeldeinformationen zu verwenden, konnten wir die geheimen Schlüssel für unsere X.509-Zertifikate, Benutzernamen und Kennwörter, Sofortnachrichten, E-Mails, geschäftskritische Dokumente und die Kommunikation stehlen. "

Jemand könnte einen privaten Schlüssel ohne Passphrase auf einen Server gestellt haben, von dem sie vermuteten, dass er nicht bösartig ist ... aber es stellte sich heraus, dass er es war. b / c-SSL-Fehler erlaubte einem Benutzer ein Passwort herauszugeben, ein Benutzer, der "sudo" hatte ... es ist wahrscheinlich kein Problem ... aber ...

Leute machen manchmal verrückte Sachen

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

Ich denke, dieses Zitat bezieht sich auf einen Mann im mittleren Angriff, der die gestohlenen TLS-Schlüssel verwendet. Ein Angreifer sollte nicht in der Lage sein, von anderen Programmen auf den Speicher zuzugreifen, da sonst ein Sicherheitsproblem im Betriebssystem hervorgehoben wird. Matthew Mitchell vor 10 Jahren 0
Wenn ein Benutzer seinen unverschlüsselten privaten SSH-Schlüssel auf Servern abgelegt hat, kann er sich nicht helfen. Senden Sie ihm einen Link zu http://piv.pivpiv.dk/. Spiff vor 10 Jahren 0