Wydanie OpenSSH 8.9 z eliminacją luki w sshd

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 przekazywanie i używanie kluczy dodanych do ssh-agent. Podsystem umożliwia ustawienie reguł określających jak i gdzie można używać kluczy w ssh-agencie. Na przykład, aby dodać klucz, którego można użyć tylko do uwierzytelnienia dowolnego użytkownika łączącego 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 host pośredni scylla.example.org możesz użyć następującego polecenia: $ ssh-add -h "[email chroniony]" \ -h "scylla.example.org" \ -h "scylla.example.org>[email chroniony]\ ~/.ssh/id_ed25519
  • W ssh i sshd do listy KexAlgorithms domyślnie dodano algorytm hybrydowy, który określa kolejność wybierania metod wymiany kluczy.[email chroniony]„(ECDH/x25519 + NTRU Prime), odporny na selekcję na komputerach kwantowych. W OpenSSH 8.9 ta metoda negocjacji została dodana pomiędzy metodami ECDH i DH, ale planuje się, że będzie ona domyślnie włączona w następnej 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 planujemy zmienić domyślne ustawienie narzędzia scp tak, aby korzystało z protokołu SFTP zamiast starszego protokołu SCP/RCP. Protokół SFTP wykorzystuje bardziej przewidywalne metody obsługi nazw i nie wykorzystuje przetwarzania powłoki wzorców glob w nazwach plików po stronie drugiego hosta, co stwarza problemy związane z bezpieczeństwem. W szczególności w przypadku 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, co w przypadku braku odpowiednich kontroli po stronie klienta pozwala na serwerowi do przesyłania innych nazw plików, różniących się od żądanych. Protokół SFTP nie ma tych problemów, ale nie obsługuje rozbudowy specjalnych ścieżek, takich jak „~/”. Aby zaradzić tej różnicy, w poprzedniej wersji OpenSSH zaproponowano nowe rozszerzenie protokołu SFTP w ramach implementacji serwera SFTP w celu rozszerzenia ścieżek ~/ i ~user/.

Źródło: opennet.ru

Dodaj komentarz