J

ednostka badawcza firmy Qualys (ang. Qualys Threat Research Unit – TRU) opublikowała szczegóły krytycznej luki w kodzie OpenSSH (sshd) umożliwiającej zdalne wykonanie kodu bez uwierzytelniania w systemach Linux opartych na glibc. CVE powiązane z tą luką to CVE-2006-5051 i CVE-2024-6387. Powodem zastosowania dwóch numerów CVE w tym wykorzystania tego z 2006 roku jest regresja, czyli powrót starego błędu. Niestety zdarza się to dość regularnie (nie w przypadku OpenSSH, ale ogólnie różnego rodzaju oprogramowania), że programiści nie dodają testów, aby upewniać się, że luki odkryte wcześniej w cyklu życia programu są pokryte łatami w przyszłych wersjach. Wersje OpenSSH starsze niż 4.4p1 są podatne na CVE-2006-5051 oraz CVE-2008-4109, z kolei OpenSSH w wersji 8.5p1 (tutaj w październiku 2020 pojawiła się regresja) do 9.8p1 (ale nie włącznie – to jest wersja poprawiona) są podatne na CVE-2024-6387 z powodu przypadkowego usunięcia krytycznego komponentu w funkcji. Ten błąd nie dotyczy systemów OpenBSD, ponieważ w 2001 roku OpenBSD opracowało bezpieczny mechanizm, który zapobiega tej luce.

Należy jednak pamiętać, że wiele dystrybucji Linuksa nie większy numerów wersji, jeśli naniosą łatkę na aktualnie używany pakiet – tylko podniesie swój wewnętrzny patchset np. z 8.9p1-3ubuntu0.7 do 8.9p1-3ubuntu0.10. Jakie dystrybucje są podatne?

• RedHat Enterprise 9
• Fedora Linux od 34 do 40
• Debian 12 (Bookworm)
• Ubuntu 22.04, 23.10, 24.04
• openSUSE Leap 15.6, Tumbleweed
• Alpine Linux od 3.14 do 3.20
• Arch Linux

Warto zaznaczyć, że luka ta opiera się na wygraniu wyścigu, czyli występuje tutaj problem z synchronizacją czasową wielu operacji, a samo wykorzystanie luki nie jest łatwe do odtworzenia – autorzy luki musieli wykonać około 10.000 prób na platformie x86 (32-bitowej), gdzie większość systemów Linux działa obecnie na architekturach 64-bitowych i ich eksploitacja wydaje się obecnie niepraktyczna. Luka może mieć jednak znaczenie w przypadku starszych systemów IoT, szczególnie jeśli nie są już dla nich dostępne poprawki bezpieczeństwa.

Mitygacja zagrożenia:

Proces sshd można chronić przed tym atakiem ustawiając odpowiedni parametr LoginGraceTime. Serwer OpenSSH nadal będzie podatny na ataki typu DoS (ang. Denial of Service), poprzez wyczerpanie wszystkich połączeń przez osobę atakującą, ale nie pozwoli na zdalne wykonanie kodu. Jako użytkownik root powinniśmy edytować plik /etc/sshd_config oraz dodać lub edytować wspomnianą opcję ustawiając jej wartość na zero:

LoginGraceTime 0

Po zapisaniu pliku należy zrestartować serwer OpenSSH:

systemctl restart sshd.service || /etc/init.d/sshd restart

Powyższe ustawienie wyłącza zdolność serwera sshd do zrywania połączeń, jeśli uwierzytelnianie nie zostanie zakończone w określonym czasie. Dlatego może to prowadzić do skutecznych ataków typu odmowa usługi (DoS). Jeśli zdecydowaliśmy się na to rozwiązanie to najlepiej połączyć je z narzędziem typu fail2ban lub zaporą ogniową *tables (a nawet techniką pukania w porty) w celu monitorowania logów i odpowiedniego limitowania połączeń na port SSH.