Po sześciu miesiącach prac zaprezentowano wydanie OpenSSH 8.9, otwartej implementacji klienta i serwera do pracy nad protokołami SSH 2.0 i SFTP. Nowa wersja sshd naprawia lukę, która może potencjalnie umożliwić nieuwierzytelniony dostęp. Problem jest spowodowany przepełnieniem liczby całkowitej w kodzie uwierzytelniającym, ale można go wykorzystać tylko w połączeniu z innymi błędami logicznymi w kodzie.
W obecnej postaci luki nie można wykorzystać, gdy włączony jest tryb separacji uprawnień, ponieważ jej manifestacja jest blokowana przez oddzielne kontrole przeprowadzane w kodzie śledzenia separacji uprawnień. Tryb separacji uprawnień jest domyślnie włączony od 2002 r., począwszy od wersji OpenSSH 3.2.2, i jest obowiązkowy od wydania OpenSSH 7.5 opublikowanego w 2017 r. Ponadto w przenośnych wersjach OpenSSH począwszy od wersji 6.5 (2014) luka jest blokowana przez kompilację z uwzględnieniem flag zabezpieczających przed przepełnieniem liczb całkowitych.
Inne zmiany:
- Przenośna wersja OpenSSH w sshd usunęła natywną obsługę mieszania haseł przy użyciu algorytmu MD5 (umożliwiając powrót do łączenia z zewnętrznymi bibliotekami, takimi jak libxcrypt).
- ssh, sshd, ssh-add i ssh-agent implementują podsystem ograniczający transfer i używanie kluczy dodanych do ssh-agent. Podsystem pozwala ustawić reguły, które określają, jak i gdzie klucze mogą być używane w ssh-agent. Na przykład, aby dodać klucz, który może być użyty do uwierzytelnienia tylko wtedy, gdy dowolny użytkownik łączy się z hostem scylla.example.org, użytkownik perseus z hostem cetus.example.org, a użytkownik medea z hostem charybdis.example.org z przekierowaniem przez hosta pośredniego scylla.example.org, możesz użyć następującego polecenia: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~/.ssh/id_ed25519
- W ssh i sshd hybrydowy algorytm „sntrup761x25519-sha512@openssh.com” (ECDH/x25519 + NTRU Prime), odporny na ataki siłowe na komputerach kwantowych, został domyślnie dodany do listy KexAlgorithms, która określa kolejność wyboru metod wymiany kluczy. W OpenSSH 8.9 ta metoda negocjacji została dodana między metodami ECDH i DH, ale planuje się, że będzie domyślnie używana w kolejnej wersji.
- ssh-keygen, ssh i ssh-agent usprawniły obsługę kluczy tokenów FIDO używanych do weryfikacji urządzeń, w tym kluczy do uwierzytelniania biometrycznego.
- Dodano polecenie „ssh-keygen -Y match-principals” do ssh-keygen w celu sprawdzenia nazw użytkowników w pliku dozwolonych nazw.
- ssh-add i ssh-agent umożliwiają dodawanie kluczy FIDO chronionych kodem PIN do ssh-agent (żądanie PIN wyświetlane jest w momencie uwierzytelnienia).
- ssh-keygen umożliwia wybór algorytmu haszującego (sha512 lub sha256) podczas generowania podpisu.
- W ssh i sshd, aby poprawić wydajność, dane sieciowe są wczytywane bezpośrednio do bufora przychodzących pakietów, z pominięciem pośredniego buforowania na stosie. Bezpośrednie umieszczanie odebranych danych w buforze kanału realizowane jest w podobny sposób.
- W ssh dyrektywa PubkeyAuthentication rozszerzyła listę obsługiwanych parametrów (yes|no|unbound|host-bound), aby zapewnić możliwość wyboru używanego rozszerzenia protokołu.
W przyszłej wersji planowane jest domyślne przełączenie narzędzia scp na SFTP, zastępując starszy protokół SCP/RCP. SFTP wykorzystuje bardziej przewidywalne metody obsługi nazw i unika niebezpiecznego przetwarzania wzorców glob w nazwach plików przez powłokę na drugim hoście. W szczególności, podczas korzystania z SCP i RCP, serwer decyduje, które pliki i katalogi wysłać do klienta, a klient jedynie sprawdza poprawność zwróconych nazw obiektów. Pozwala to na naruszenia bezpieczeństwa, jeśli po stronie klienta nie zostaną przeprowadzone odpowiednie kontrole. serwer Prześlij nazwy plików inne niż żądane. Protokół SFTP jest wolny od tych problemów, ale nie obsługuje rozszerzania ścieżek specjalnych, takich jak „~/”. Aby rozwiązać tę różnicę, w poprzedniej wersji OpenSSH implementacji serwera SFTP zaproponowano nowe rozszerzenie protokołu SFTP, które rozszerza ścieżki ~/ i ~user/.
Źródło: opennet.ru
