Czy Heartbleed wpływa na klucze ssh?

40

Czy ostatni błąd Heartbleed wpływa na klucze ssh, które wygenerowałem i używam do wypychania / pobierania kodu za pomocą Github, Heroku i innych podobnych stron?

Czy muszę wymienić klucze, których używałem?

LikeMaBell
źródło

Odpowiedzi:

47

Nie, Heartbleed tak naprawdę nie wpływa na klucze SSH, więc prawdopodobnie nie musisz wymieniać używanych kluczy SSH.

Po pierwsze, SSL i SSH to dwa różne protokoły bezpieczeństwa dla dwóch różnych zastosowań. Podobnie OpenSSL i OpenSSH są również dwoma całkowicie różnymi pakietami oprogramowania, pomimo podobieństw w ich nazwach.

Po drugie, exploit Heartbleed powoduje, że wrażliwy peer OpenSSL TLS / DTLS zwraca losowe 64kB pamięci, ale prawie na pewno ogranicza się do pamięci dostępnej dla tego procesu korzystającego z OpenSSL. Jeśli ten proces korzystający z OpenSSL nie ma dostępu do twojego prywatnego klucza SSH, to nie może go wyciec za pośrednictwem Heartbleed.

Ponadto zwykle umieszczasz swój klucz publiczny SSH tylko na serwerach, z którymi używasz SSH do łączenia się, a jak sama nazwa wskazuje, klucz publiczny jest kluczem, który możesz opublikować. Nie ma znaczenia, kto to wie. W rzeczywistości chcesz, aby społeczeństwo znało Twój poprawny klucz publiczny.

Podziękowania dla @Bob za wskazanie, że luka może wpływać na aplikacje klienckie, które używają podatnych wersji OpenSSL jako swojej biblioteki TLS / DTLS po stronie klienta. Jeśli więc, na przykład, twoja przeglądarka internetowa lub klient VPN oparty na SSL użył podatnej wersji OpenSSL i połączył się ze złośliwym serwerem, ten złośliwy serwer może użyć Heartbleed, aby zobaczyć losowe fragmenty pamięci tego oprogramowania klienckiego. Jeśli z jakiegoś powodu ta aplikacja kliencka miała kopię twoich kluczy prywatnych SSH w pamięci, mogłaby wyciekać przez Heartbleed.

Nie mam na myśli żadnego oprogramowania poza SSH, które mogłoby mieć kopię twojego niezaszyfrowanego klucza prywatnego SSH w pamięci. Zakłada się, że Twoje klucze prywatne SSH są zaszyfrowane na dysku. Jeśli nie trzymasz swoich kluczy prywatnych SSH zaszyfrowanych na dysku, to przypuszczam, że mógłbyś użyć programu do przesyłania plików lub tworzenia kopii zapasowych OpenSSL TLS do kopiowania lub tworzenia kopii zapasowej katalogu domowego przez sieć (w tym ~/.ssh/id_rsaklucz prywatny SSH lub inny ), może mieć w pamięci niezaszyfrowaną kopię klucza prywatnego SSH. Z drugiej strony, jeśli tworzysz kopię zapasową niezaszyfrowanego klucza prywatnego SSH na złośliwym serwerze, prawdopodobnie masz większe obawy niż Heartbleed. :-)

Spiff
źródło
3
Pamiętaj, że komentarz publiczny naprawdę nie ma znaczenia - Heartbleed wpływa zarówno na klientów, jak i na serwery. Ale masz rację, że SSH jest inna i nie ma na nią wpływu ta szczególna luka .
Bob
1
@ Bob Dzięki, zapisy Heartbleed były tak skoncentrowane na serwerze, że nie zdawałem sobie sprawy z konsekwencji po stronie klienta. Zaktualizowałem moją odpowiedź, aby lepiej to rozwiązać. Nadal uważam, że ludzie raczej nie zostawili gdzieś prywatnego klucza SSH, aby proces podatny na Heartbleed mógł go wyciec.
Spiff,
1
Należy wspomnieć, że SSH używa biblioteki OpenSSL do szyfrowania. Jak już wspomniałeś, exploit nie ma wpływu na ssh, ponieważ jest to inny protokół.
psibar
1

„Po drugie, exploit Heartbleed powoduje, że wrażliwy peer OpenSSL TLS / DTLS zwraca losowe 64kB pamięci, ale prawie na pewno ogranicza się do pamięci dostępnej dla tego procesu wykorzystującego OpenSSL.”

jeśli maszyna zostanie naruszona, to jak możesz na niej cokolwiek zaufać, w tym ssh? z heartbleed.com

„Co przecieka w praktyce?

Przetestowaliśmy niektóre nasze usługi z perspektywy atakującego. Zaatakowaliśmy się z zewnątrz, nie pozostawiając śladu. Bez użycia uprzywilejowanych informacji lub poświadczeń byliśmy w stanie wykraść od siebie tajne klucze używane do naszych certyfikatów X.509, nazw użytkowników i haseł, wiadomości błyskawicznych, wiadomości e-mail oraz dokumentów i komunikacji o znaczeniu krytycznym dla firmy. „

ktoś mógł umieścić klucz prywatny, bez hasła, na serwerze, który, jak zakładali, nie był złośliwy ... ale okazał się być. b / c Błąd SSL pozwolił na usunięcie hasła użytkownika, użytkownika, który miał „sudo” ... prawdopodobnie nie jest to problem… ale…

ludzie czasem robią szalone rzeczy

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

Don Bright
źródło
Myślę, że ten cytat odnosi się do człowieka w środku ataku za pomocą skradzionych kluczy TLS. Osoba atakująca nie powinna mieć dostępu do pamięci z innych programów, w przeciwnym razie wskazuje to na problem bezpieczeństwa w systemie operacyjnym.
Matthew Mitchell,
Jeśli użytkownik umieszcza swój niezaszyfrowany prywatny klucz SSH na serwerach, to jest on poza naszą pomocą. Wyślij mu link do piv.pivpiv.dk .
Spiff