Po pięciu miesiącach prac zaprezentowano wydanie OpenSSH 8.5, otwartej implementacji klienta i serwera do pracy poprzez protokoły SSH 2.0 i SFTP.
Twórcy OpenSSH przypomnieli o zbliżającym się wycofywaniu algorytmów wykorzystujących skróty SHA-1 ze względu na zwiększoną skuteczność ataków kolizyjnych z danym prefiksem (koszt wybrania kolizji szacowany jest na około 50 tys. dolarów). W jednej z nadchodzących wydań planują domyślnie wyłączyć możliwość korzystania z algorytmu podpisu cyfrowego klucza publicznego „ssh-rsa”, który jest wspomniany w oryginalnym dokumencie RFC dotyczącym protokołu SSH i pozostaje szeroko rozpowszechniony w praktyce.
Aby przetestować użycie ssh-rsa w swoich systemach, możesz spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”. Jednocześnie domyślne wyłączenie podpisów cyfrowych „ssh-rsa” nie oznacza całkowitej rezygnacji z używania kluczy RSA, ponieważ oprócz SHA-1 protokół SSH umożliwia stosowanie innych algorytmów obliczania skrótu. W szczególności oprócz „ssh-rsa” nadal możliwe będzie korzystanie z pakietów „rsa-sha2-256” (RSA/SHA256) i „rsa-sha2-512” (RSA/SHA512).
Aby ułatwić przejście na nowe algorytmy, OpenSSH 8.5 ma domyślnie włączone ustawienie UpdateHostKeys, które pozwala klientom automatycznie przełączać się na bardziej niezawodne algorytmy. Za pomocą tego ustawienia włączane jest specjalne rozszerzenie protokołu „[email chroniony]", pozwalając serwerowi po uwierzytelnieniu poinformować klienta o wszystkich dostępnych kluczach hosta. Klient może odzwierciedlić te klucze w swoim pliku ~/.ssh/known_hosts, co umożliwia aktualizację kluczy hosta i ułatwia zmianę kluczy na serwerze.
Korzystanie z UpdateHostKeys jest ograniczone kilkoma zastrzeżeniami, które mogą zostać usunięte w przyszłości: klucz musi być wymieniony w pliku UserKnownHostsFile, a nie używany w pliku GlobalKnownHostsFile; klucz musi występować tylko pod jedną nazwą; nie należy używać certyfikatu klucza hosta; w znanych_hostach nie należy używać masek według nazwy hosta; ustawienie VerifyHostKeyDNS musi być wyłączone; Parametr UserKnownHostsFile musi być aktywny.
Zalecane algorytmy migracji obejmują rsa-sha2-256/512 oparty na RFC8332 RSA SHA-2 (obsługiwany od OpenSSH 7.2 i używany domyślnie), ssh-ed25519 (obsługiwany od OpenSSH 6.5) i ecdsa-sha2-nistp256/384/521 na RFC5656 ECDSA (obsługiwane od OpenSSH 5.7).
Inne zmiany:
- Zmiany bezpieczeństwa:
- W ssh-agent naprawiono lukę spowodowaną ponownym zwolnieniem już zwolnionego obszaru pamięci (double-free). Problem występuje od wydania OpenSSH 8.2 i może zostać potencjalnie wykorzystany, jeśli osoba atakująca uzyska dostęp do gniazda ssh-agent w systemie lokalnym. Eksploatację utrudnia fakt, że dostęp do gniazda mają tylko root i pierwotny użytkownik. Najbardziej prawdopodobny scenariusz ataku polega na przekierowaniu agenta na konto kontrolowane przez osobę atakującą lub na host, na którym osoba atakująca ma dostęp do konta root.
- sshd dodał zabezpieczenie przed przekazywaniem bardzo dużych parametrów wraz z nazwą użytkownika do podsystemu PAM, co pozwala blokować podatności w modułach systemu PAM (Pluggable Authentication Module). Na przykład zmiana uniemożliwia wykorzystanie sshd jako wektora do wykorzystania niedawno odkrytej luki root w systemie Solaris (CVE-2020-14871).
- Potencjalnie zakłócające zmiany kompatybilności:
- W ssh i sshd przeprojektowano eksperymentalną metodę wymiany kluczy, która jest odporna na zgadywanie na komputerze kwantowym. Komputery kwantowe radykalnie szybciej rozwiązują problem rozkładu liczby naturalnej na czynniki pierwsze, który leży u podstaw współczesnych algorytmów szyfrowania asymetrycznego i którego nie można skutecznie rozwiązać na klasycznych procesorach. Zastosowana metoda opiera się na algorytmie NTRU Prime opracowanym dla kryptosystemów postkwantowych oraz metodzie wymiany kluczy na krzywej eliptycznej X25519. Zamiast [email chroniony] metoda jest teraz identyfikowana jako [email chroniony] (algorytm sntrup4591761 został zastąpiony przez sntrup761).
- W ssh i sshd zmieniono kolejność ogłaszania obsługiwanych algorytmów podpisu cyfrowego. ED25519 jest teraz oferowany jako pierwszy zamiast ECDSA.
- W ssh i sshd ustawienie parametrów jakości usług TOS/DSCP dla sesji interaktywnych odbywa się teraz przed ustanowieniem połączenia TCP.
- Obsługa szyfrów została wycofana w ssh i sshd [email chroniony], który jest identyczny z aes256-cbc i był używany przed zatwierdzeniem RFC-4253.
- Domyślnie parametr CheckHostIP jest wyłączony, co daje znikome korzyści, ale jego użycie znacznie komplikuje rotację kluczy dla hostów znajdujących się za modułami równoważenia obciążenia.
- Do sshd dodano ustawienia PerSourceMaxStartups i PerSourceNetBlockSize, aby ograniczyć intensywność uruchamiania programów obsługi na podstawie adresu klienta. Parametry te umożliwiają dokładniejszą kontrolę limitu uruchomień procesów w porównaniu z ogólnym ustawieniem MaxStartups.
- Do ssh i sshd dodano nowe ustawienie LogVerbose, które pozwala na wymuszenie podnieść poziom informacji debugowania zrzucanych do dziennika, z możliwością filtrowania według szablonów, funkcji i plików.
- W ssh, podczas akceptowania nowego klucza hosta, wyświetlane są wszystkie nazwy hostów i adresy IP powiązane z kluczem.
- ssh pozwala opcji UserKnownHostsFile=none wyłączyć użycie pliku znane_hosty podczas identyfikowania kluczy hosta.
- Do ssh_config dla ssh dodano ustawienie KnownHostsCommand, umożliwiające uzyskanie danych znanych_hostów z danych wyjściowych określonego polecenia.
- Dodano opcję PermitRemoteOpen do ssh_config dla ssh, aby umożliwić ograniczenie miejsca docelowego podczas korzystania z opcji RemoteForward w SOCKS.
- W ssh dla kluczy FIDO powtórne żądanie PIN-u realizowane jest w przypadku niepowodzenia operacji podpisu cyfrowego z powodu błędnego PIN-u i braku monitu o podanie PIN-u przez użytkownika (np. gdy nie udało się uzyskać prawidłowych danych biometrycznych i urządzenie wróciło do ręcznego wprowadzania kodu PIN).
- sshd dodaje obsługę dodatkowych wywołań systemowych do mechanizmu izolacji procesów opartego na seccomp-bpf w systemie Linux.
- Narzędzie contrib/ssh-copy-id zostało zaktualizowane.
Źródło: opennet.ru