Wersja OpenSSH 8.3 z poprawką luki w zabezpieczeniach scp

Po trzech miesiącach rozwoju przedstawione wydanie OpenSSH 8.3, otwarta implementacja klienta i serwera do pracy poprzez protokoły SSH 2.0 i SFTP.

Nowa wersja dodaje ochronę przed atakami scp, które pozwalają serwerowi przekazywać inne nazwy plików niż żądane (w przeciwieństwie do podatność z przeszłości, atak nie umożliwia zmiany wybranego przez użytkownika katalogu ani maski globu). Przypomnijmy, że w SCP serwer decyduje, które pliki i katalogi wysłać do klienta, a klient jedynie sprawdza poprawność zwróconych nazw obiektów. Istota zidentyfikowanego problemu polega na tym, że w przypadku niepowodzenia wywołania systemowego utimes zawartość pliku jest interpretowana jako metadane pliku.

Ta funkcja podczas łączenia się z serwerem kontrolowanym przez atakującego może zostać wykorzystana do zapisania innych nazw plików i innej zawartości w systemie plików użytkownika podczas kopiowania przy użyciu scp w konfiguracjach, które prowadzą do niepowodzenia podczas wywoływania utimes (na przykład, gdy utimes jest zabronione przez polityka SELinux lub filtr wywołań systemowych). Prawdopodobieństwo rzeczywistych ataków szacuje się na minimalne, ponieważ w typowych konfiguracjach wywołanie utimes nie kończy się niepowodzeniem. Ponadto atak nie pozostaje niezauważony - przy wywołaniu scp wyświetla się błąd przesyłania danych.

Ogólne zmiany:

• W sftp zatrzymano przetwarzanie argumentu „-1”, podobnie jak w przypadku ssh i scp, które zostało wcześniej zaakceptowane, ale zignorowane;
• W sshd podczas korzystania z IgnoreRhosts są teraz trzy możliwości: „tak” – ignoruj ​​​​rhosts/shosts, „nie” – szanuj rhosts/shosts i „shosts-only” – zezwalaj na „.shosts”, ale nie zezwalaj na „.rhosts”;
• Ssh obsługuje teraz podstawienie %TOKEN w ustawieniach LocalFoward i RemoteForward używanych do przekierowywania gniazd Uniksa;
• Zezwalaj na ładowanie kluczy publicznych z niezaszyfrowanego pliku kluczem prywatnym, jeśli nie ma osobnego pliku z kluczem publicznym;
• Jeśli w systemie dostępna jest biblioteka libcrypto, ssh i sshd korzystają teraz z implementacji algorytmu chacha20 z tej biblioteki zamiast wbudowanej implementacji przenośnej, która jest słabsza pod względem wydajności;
• Zaimplementowano możliwość zrzutu zawartości binarnej listy unieważnionych certyfikatów podczas wykonywania polecenia „ssh-keygen -lQf /path”;
• Wersja przenośna implementuje definicje systemów, w których sygnały z opcją SA_RESTART przerywają operację wyboru;
• Rozwiązano problemy z montażem na systemach HP/UX i AIX;
• Naprawiono problemy z budowaniem piaskownicy seccomp w niektórych konfiguracjach Linuksa;
• Poprawione wykrywanie biblioteki libfido2 i rozwiązane problemy z kompilacją dzięki opcji „--with-security-key-builtin”.

Twórcy OpenSSH również po raz kolejny ostrzegali przed zbliżającą się dekompozycją algorytmów wykorzystujących skróty SHA-1 z powodu awans skuteczność ataków kolizyjnych z danym prefiksem (koszt wybrania kolizji szacuje się na około 45 tysięcy 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 dla protokołu SSH i pozostaje szeroko rozpowszechniony w praktyce (w celu przetestowania użycia ssh-rsa w swoich systemach, możesz spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”).

Aby płynnie przejść na nowe algorytmy w OpenSSH, w przyszłej wersji ustawienie UpdateHostKeys zostanie domyślnie włączone, co automatycznie przeniesie klientów do bardziej niezawodnych algorytmów. Zalecane algorytmy migracji obejmują rsa-sha2-256/512 w oparciu o RFC8332 RSA SHA-2 (obsługiwane od OpenSSH 7.2 i używane domyślnie), ssh-ed25519 (obsługiwane od OpenSSH 6.5) i ecdsa-sha2-nistp256/384/521 na RFC5656 ECDSA (obsługiwane od OpenSSH 5.7).

W ostatniej wersji „ssh-rsa” i „diffie-hellman-group14-sha1” zostały usunięte z listy CASignatureAlgorithms, która definiuje algorytmy umożliwiające cyfrowe podpisywanie nowych certyfikatów, ponieważ użycie SHA-1 w certyfikatach stwarza dodatkowe ryzyko dzięki temu atakujący ma nieograniczony czas na poszukiwanie kolizji dla istniejącego certyfikatu, natomiast czas ataku na klucze hosta jest ograniczony limitem czasu połączenia (LoginGraceTime).

Źródło: opennet.ru