Wydanie OpenSSH 8.5

Po pięciu miesiącach rozwoju zaprezentowano wydanie OpenSSH 8.5, otwartej implementacji klienta i serwera do pracy w protokołach SSH 2.0 i SFTP.

Programiści OpenSSH przypomnieli o nadchodzącym przejściu do kategorii przestarzałych algorytmów używających haszy SHA-1, w związku z zwiększoną efektywnością ataków kolizyjnych z określonym prefiksem (koszt znalezienia kolizji szacuje się na około 50 tysięcy dolarów). W jednym z najbliższych wydań planuje się domyślne wyłączenie możliwości korzystania z algorytmu podpisów cyfrowych za pomocą klucza publicznego „ssh-rsa”, który jest wspomniany w oryginalnym RFC dla protokołu SSH i nadal pozostaje powszechnie stosowany w praktyce.

Aby sprawdzić zastosowanie ssh-rsa w swoich systemach, można spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”. Jednak wyłączenie domyślnie cyfrowych podpisów „ssh-rsa” nie oznacza całkowitego zaprzestania używania kluczy RSA, ponieważ poza SHA-1 protokół SSH dopuszcza użycie innych algorytmów obliczania hashy. W szczególności, oprócz „ssh-rsa”, pozostanie możliwość zastosowania zestawów „rsa-sha2-256” (RSA/SHA256) i „rsa-sha2-512” (RSA/SHA512).

Aby ułatwić przejście na nowe algorytmy, w OpenSSH 8.5 domyślnie włączona jest opcja UpdateHostKeys, która pozwala na automatyczne przejście klientów na bardziej niezawodne algorytmy. Włącza ona specjalne rozszerzenie protokołu „hostkeys@openssh.com”, które pozwala serwerowi po zakończeniu autoryzacji informować klienta o wszystkich dostępnych kluczach hosta. Klient może odzwierciedlić te klucze w swoim pliku ~/ .ssh/known_hosts, co pozwala zorganizować aktualizację kluczy hosta i upraszcza zmianę kluczy. serwerze.

Użycie UpdateHostKeys jest ograniczone kilkoma zastrzeżeniami, które mogą zostać w przyszłości uchylone: klucz musi być wymieniony w UserKnownHostsFile i nie może być używany w GlobalKnownHostsFile; klucz musi występować tylko pod jedną nazwą; nie może być używany certyfikat klucza hosta; w known_hosts nie mogą być stosowane maski po nazwie hosta; musi być wyłączona opcja VerifyHostKeyDNS; musi być aktywny parametr UserKnownHostsFile.

Wśród zalecanych do migracji algorytmów wymienione zostały rsa-sha2-256/512 na podstawie RFC8332 RSA SHA-2 (obsługiwany od OpenSSH 7.2 i używany domyślnie), ssh-ed25519 (obsługiwany od OpenSSH 6.5) oraz ecdsa-sha2-nistp256/384/521 na podstawie RFC5656 ECDSA (obsługiwany od OpenSSH 5.7).

Inne zmiany:

• Zmiany związane z bezpieczeństwem:
  • W ssh-agent naprawiono lukę bezpieczeństwa spowodowaną podwójnym zwolnieniem już zwolnionej pamięci (double-free). Problem pojawił się w wersji OpenSSH 8.2 i potencjalnie może być wykorzystywany przez atakującego mającego dostęp do gniazda ssh-agent w lokalnym systemie. Utrudnia to fakt, że dostęp do gniazda mają tylko użytkownicy root oraz pierwotny użytkownik. Najbardziej prawdopodobnym scenariuszem ataku jest przekierowanie agenta na konto, które jest kontrolowane przez złośliwego użytkownika, lub na host, na którym złośliwy użytkownik ma dostęp roota.
  • W sshd dodano zabezpieczenie przed przesyłaniem bardzo dużych parametrów o nazwie użytkownika do podsystemu PAM, co pozwala zablokować luki w systemowych modułach PAM (Pluggable Authentication Module). Na przykład zmiana ta może zapobiec wykorzystaniu sshd jako wektora do eksploatacji niedawno wykrytej luki roota w Solaris (CVE-2020-14871).
• Zmiany potencjalnie naruszające zgodność:
  • W ssh i sshd opracowano eksperymentalną metodę wymiany kluczy odporną na ataki kwantowe. Komputery kwantowe znacznie szybciej rozwiązują problem rozkładu liczby naturalnej na czynniki pierwsze, który jest podstawą współczesnych asymetrycznych algorytmów szyfrowania i nie jest efektywnie rozwiązywalny przez klasyczne procesory. Używana metoda opiera się na algorytmie NTRU Prime, zaprojektowanym dla kryptosystemów odpornych na ataki kwantowe, oraz metodzie wymiany kluczy na bazie krzywych eliptycznych X25519. Zamiast sntrup4591761x25519-sha512@tinyssh.org metoda jest teraz identyfikowana jako sntrup761x25519-sha512@openssh.com (algorytm sntrup4591761 zastąpiono sntrup761).
  • W ssh i sshd zmieniono kolejność ogłaszania obsługiwanych algorytmów podpisów cyfrowych. Pierwsza jest teraz oferowana ED25519 zamiast ECDSA.
  • W ssh i sshd ustawienia parametrów jakości usług TOS/DSCP dla interaktywnych sesji są teraz realizowane przed nawiązaniem połączenia TCP.
  • W ssh i sshd zakończono wsparcie dla szyfru rijndael-cbc@lysator.liu.se, który jest identyczny z aes256-cbc i był używany przed zatwierdzeniem RFC-4253.
  • Domyślnie wyłączono parametr CheckHostIP, którego korzyści są nieznaczne, ale jego użycie znacząco komplikuje rotację kluczy dla hostów za równoważnikami obciążenia.
• W sshd dodano ustawienia PerSourceMaxStartups i PerSourceNetBlockSize, aby ograniczyć intensywność uruchamiania procesów związanych z adresem klienta. Wskazane parametry pozwalają na bardziej szczegółowe zarządzanie ograniczeniami uruchamiania procesów w porównaniu do ogólnego ustawienia MaxStartups.
• W ssh i sshd dodano nowe ustawienie LogVerbose, które umożliwia wymuszenie podniesienia poziomu rejestrowanych informacji debugujących, z możliwością filtrowania według wzorców, funkcji i plików.
• W ssh przy akceptacji nowego klucza hosta zapewniono prezentację wszystkich nazw hostów i adresów IP, skojarzonych z kluczem.
• W ssh zezwolono na wskazanie opcji UserKnownHostsFile=none, aby wyłączyć użycie pliku known_hosts przy identyfikacji kluczy hosta.
• W ssh_config dla ssh dodano ustawienie KnownHostsCommand, które pozwala na uzyskanie danych known_hosts z wyjścia określonej komendy.
• W ssh_config dla ssh dodano opcję PermitRemoteOpen, która pozwala na ograniczenie punktu docelowego przy użyciu opcji RemoteForward z SOCKS.
• W ssh dla kluczy FIDO zapewniono ponowną prośbę o PIN w przypadku niepowodzenia operacji podpisu cyfrowego z powodu niepoprawnego PIN-u oraz braku prośby o PIN u użytkownika (na przykład, gdy nie udało się uzyskać poprawnych danych biometrycznych i urządzenie wróciło do ręcznego wprowadzenia PIN-u).
• W sshd dodano wsparcie dla dodatkowych wywołań systemowych w mechanizmie izolacji procesu opartym na seccomp-bpf na platformie Linux.
• Zaktualizowano narzędzie contrib/ssh-copy-id.

Źródło: opennet.ru