Wydanie OpenSSH 8.3 z poprawką dla podatności w scp

Po trzech miesiącach prac rozwojowych zaprezentowano wydanie OpenSSH 8.3, otwartą implementację klienta i serwera do pracy z protokołami SSH 2.0 i SFTP.

W nowym wydaniu dodano zabezpieczenie przed atakiem na scp, umożliwiające serwerowi przesyłanie innych nazw plików, które różnią się od żądanych (w przeciwieństwie do poprzedniej podatności, atak nie pozwala na zmianę wybranego przez użytkownika katalogu lub maski glob). Przypomnijmy, że w SCP serwer podejmuje decyzję, które pliki i katalogi wysłać do klienta, a klient jedynie sprawdza poprawność zwróconych nazw obiektów. Istota wykrytego problemu polega na tym, że jeśli wywołanie systemowe utimes kończy się błędem, zawartość pliku jest interpretowana jako metadane pliku.

Ta cecha przy łączeniu z serwerem kontrolowanym przez przestępcę może być używana do zachowania w FS użytkownika innych nazw plików i innej zawartości podczas kopiowania za pomocą scp w konfiguracjach, które prowadzą do awarii podczas wywoływania utimes (na przykład podczas zakazu utimes przez politykę SELinux lub filtr wywołań systemowych). Prawdopodobieństwo przeprowadzenia rzeczywistych ataków ocenia się jako minimalne, ponieważ w typowych konfiguracjach wywołanie utimes nie kończy się awarią. Ponadto atak nie przechodzi niezauważony — podczas wywołania scp pojawia się błąd przesyłania danych.

Ogólne zmiany:

• W sftp zrezygnowano z obsługi argumentu „-1” analogicznie do ssh i scp, który wcześniej był akceptowany, ale ignorowany.
• W sshd podczas korzystania z IgnoreRhosts teraz dostępne są trzy opcje: „yes” — ignorować rhosts/shosts, „no” — uwzględnić rhosts/shosts oraz „shosts-only” — zezwolić na „.shosts”, ale zabronić „.rhosts”.
• W ssh zapewniono przetwarzanie podstawienia %TOKEN w ustawieniach LocalForward i RemoteForward, używanych do przekierowywania gniazd Unix;
• Zezwolono na ładowanie kluczy publicznych z niezaszyfrowanego pliku zawierającego prywatny klucz, jeśli nie ma oddzielnego pliku z kluczem publicznym;
• W przypadku istnienia w systemie libcrypto, ssh i sshd teraz używają implementacji algorytmu chacha20 z tej biblioteki, zamiast wbudowanej przenośnej implementacji, która pozostaje w tyle pod względem wydajności;
• Wprowadzono możliwość zrzutu zawartości binarnej listy odwołanych certyfikatów podczas wykonywania polecenia „ssh-keygen -lQf /path”.
• W przenośnej wersji zrealizowano określenie systemów, w których sygnały z opcją SA_RESTART przerywają działanie select;
• Rozwiązano problemy ze składaniem w systemach HP/UX i AIX;
• Problemy z kompilacją sandboxa seccomp w niektórych konfiguracjach Linuksa zostały rozwiązane;
• Udoskonalono wykrywanie biblioteki libfido2 i rozwiązano problemy z kompilacją z opcją „—with-security-key-builtin”.

Programiści OpenSSH ponownie ostrzegli o nadchodzącej deprecjacji algorytmów wykorzystujących hashe SHA-1 w związku z podwyższeniem efektywności ataków kolizyjnych z określonym prefiksem (koszt wytrychania kolizji szacowany jest na około 45 tysięcy dolarów). W jednym z nadchodzących wydań planowane jest domyślne wyłączenie możliwości korzystania z algorytmu cyfrowych podpisów opartego na publicznym kluczu „ssh-rsa”, który jest wspomniany w oryginalnym RFC dla protokołu SSH i pozostaje szeroko stosowany w praktyce (aby sprawdzić użycie ssh-rsa w swoich systemach, można spróbować połączyć się przez ssh z opcją „-oHostKeyAlgorithms=-ssh-rsa”).

Aby ułatwić przejście na nowe algorytmy w OpenSSH, w jednym z następnych wydań domyślnie włączona zostanie opcja UpdateHostKeys, która automatycznie przeniesie klientów na bardziej niezawodne algorytmy. Wśród zalecanych algorytmów do migracji wymienione są rsa-sha2-256/512 na podstawie RFC8332 RSA SHA-2 (wsparcie od OpenSSH 7.2 i używane domyślnie), ssh-ed25519 (wsparcie od OpenSSH 6.5) oraz ecdsa-sha2-nistp256/384/521 na podstawie RFC5656 ECDSA (wsparcie od OpenSSH 5.7).

Od ostatniego wydania „ssh-rsa” i „diffie-hellman-group14-sha1” zostały usunięte z listy CASignatureAlgorithms, określającej algorytmy dozwolone do cyfrowego podpisu nowych certyfikatów, ponieważ użycie SHA-1 w certyfikatach wiąże się z dodatkowym ryzykiem, ponieważ atakujący ma nieograniczony czas na znalezienie kolizji dla istniejącego certyfikatu, podczas gdy czas ataku na klucze hosta jest ograniczony czasem oczekiwania na połączenie (LoginGraceTime).

Źródło: opennet.ru