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?
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?
Odpowiedzi:
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. :-)
„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/