Poważna luka z przeszłości znów niebezpieczna. Łatajcie swoje serwery OpenSSH! “regreSSHion” atakuje – zdalne wykonanie poleceń jako root

OpenSSH to jeden z bezpieczniejszych i dobrze przebadanych projektów. Jednak gdy pojawia się krytyczna podatność dotykająca tego kluczowego elementu dla bezpieczeństwa wielu systemów, należy podjąć natychmiastowe kroki.

CVE-2024-6387 to krytyczna podatność typu RCE (Remote Code Execution) pozwalająca na wykonanie kodu na zdalnym systemie korzystającym z glibc z uruchomioną usługą OpenSSH jako root bez uwierzytelnienia! Luka dotyczy OpenSSH w wersji poniżej 4.4p1 oraz od wersji 8.5p1 (włącznie) do wersji poniżej 9.8p1 (należy to rozumieć tak, że 9.8p1 jest już bezpieczna). Badacze z Qualys, którzy odkryli ten błąd wskazują, że obecnie w Internecie widocznych jest ponad 14 milionów instancji, które potencjalnie mogą być podatne na ten atak (jak zauważa zespół Qualysa – podatna jest przede wszystkim domyślna konfiguracja). W tym miejscu zalecamy przerwanie czytania niniejszego artykułu, zaktualizowanie swoich serwerów oraz powrócenie do lektury o genezach powstania luki po zakończeniu tego procesu.

Większość dystrybucji wprowadziła już niezbędne poprawki zanim zdjęto embargo informacyjne oraz opublikowało stosowne biuletyny informacyjne:

Ubuntu: https://ubuntu.com/security/CVE-2024-6387

Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=2294604, https://access.redhat.com/security/cve/CVE-2024-6387

Debian: https://security-tracker.debian.org/tracker/CVE-2024-6387

SUSE Linux: https://www.suse.com/security/cve/CVE-2024-6387.html

Wiele dystrybucji wciąż nie wypuściło łatek. Jednym z przykładów jest Kali Linux (dystrybucja dla pentesterów).

Nazwa podatności jest nieprzypadkowa, “regreSSHion” to powrót błędu sklasyfikowanego w roku 2006 jako CVE-2006-5051, czyli sytuacji wyścigu (ang. race-condition) w kodzie obsługującym sygnały (ang. signal handler). Pierwotnie, zgłoszenie zostało opisane jako atak odmowy usługi i potencjalnie wykonanie kodu. Sytuacja została naprawiona w OpenSSH 4.4p1. Autorem oryginalnego znaleziska jest Mark Dowd. Okazuje się, że w październiku 2020 dokonano zmian (commit: 752250c) i usunięto makro #ifdef DO_LOG_SAFE_IN_SIGHAND wprowadzając ponownie błąd w wersji 8.5p1 (brak informacji czy to przeoczenie czy celowa ingerencja)! Ponieważ problem występuje w obsłudze sygnałów w krytycznej, uprzywilejowanej części kodu uruchamianej bez sandboxa – skutkiem jest wykonanie kodu w kontekście roota. Wprowadzone w czerwcu poprawki przesuwają kod będący źródłem podatności do wyizolowanych procesów, w których może on być wykonywany synchronicznie:

On June 6, 2024, this signal handler race condition was fixed by commit

81c1099 („Add a facility to sshd(8) to penalise particular problematic

client behaviours”), which moved the async-signal-unsafe code from

sshd’s SIGALRM handler to sshd’s listener process, where it can be

handled synchronously

LoginGraceTime to parametr konfiguracyjny, definiujący jak długo serwer może utrzymywać nieuwierzytelnione połączenie. Domyślnie jest to 120 sekund (w starszych wersjach 600). W momencie gdy klientowi nie uda się poprawnie uwierzytelnić, uruchamiana jest obsługa SIGALRM, która wywołuje wiele funkcji nie będących “async-signal-safe”, jak np. syslog(). To pozwala na przerwanie działania kodu, który pozostawi stan procesu (np. sterty) w formie, który umożliwia późniejszą eksploitację. Szczegóły ataków wycelowanych w poszczególne wersje, zostały opisane w advisory.
W serwisie GitHub został opublikowany PoC na wersję 32 bitową ale należy podejść do niego ze szczególną ostrożnością. Autorzy zaznaczają, że testowali eksploitację w kontrolowanym środowisku sieci lokalnej oraz maszyn wirtualnych co znacznie redukowało jitter sieci. Z powodu ograniczeń nałożonych na proces eksploitacji, wygranie wyścigu i otrzymanie zdalnego wykonania kodu jest stosunkowo trudne:

  In our experiments, it takes ~10,000 tries on average to win this race

  condition, so ~3-4 hours with 100 connections (MaxStartups) accepted

  per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on

  average to obtain a remote root shell, because we can only guess the

  glibc’s address correctly half of the time (because of ASLR).

Autorzy przewidują, że wygranie wyścigu dla nowszych architektur może potrwać do tygodnia, ale dopiero praktyczne testy pozwolą sprawdzić tę teorię:

With a heap corruption as a primitive, two FILE structures malloc()ated

in the heap, and 21 fixed bits in the glibc’s addresses, we believe that

this signal handler race condition is exploitable on amd64 (probably not

in ~6-8 hours, but hopefully in less than a week). Only time will tell.

Jeśli nasze serwery nie posiadają  dostępnej poprawionej wersji OpenSSH istnieje kilka sposobów na tymczasowe rozwiązanie. Zespół badaczy Qualysa sugeruje usunięcie lub zakomentowanie niebezpiecznego kodu z funkcji sshsigdie():

sshsigdie(const char *file, const char *func, int line, int showfunc,

    LogLevel level, const char *suffix, const char *fmt, ...)

{

#if 0

        va_list args;

        va_start(args, fmt);

        sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL,

            suffix, fmt, args);

        va_end(args);

#endif

        _exit(1);

}

Listing 1. Przykładowa, sugerowana zmiana w funkcji sshsigdie() (źródło: Qualys)

Jeśli nie jest możliwa aktualizacja bądź przebudowanie binariów, sugerowanym rozwiązaniem jest ustawienie parametru LoginGraceTime na 0. To spowoduje, że sshd będzie podatne na atak odmowy usługi jeśli wyczerpana zostanie pula nieuwierzytelnionych połączeń (definiowana przez MaxStartups), ale uniemożliwi to RCE. 

Tymczasowo można ograniczyć dostęp do portu, na którym nasłuchuje usługa. Dostępne są tu różne opcje, począwszy od uruchomienia knockd, po uruchomienie bastion host z dystrybucją, w której SSH zostało załatane i ograniczenie dostępu do naszych maszyn tylko do IP tego hosta.

Aktualizacja: 04.07.2024 23:30

Dziękujemy za czujność, jednak nie pomyliliśmy wersji. OpenSSH jest aktywnie rozwijane w wielu wersjach, a co za tym idzie dystrybucje w swoich repozytoriach mogą posiadać różne wersje OpenSSH. Nasz wpis odnosi się do oficjalnych wydań OpenSSH, tak samo jak advisory opublikowane przez Qualysa. Oczywiście łatki bezpieczeństwa są aktywnie backportowane na poszczególne wersje oferowane przez dystrybucje, stąd pewnie te sugestie. 
Zgodnie z informacją dostępną tutaj, łatka znajduje się w repozytorium stabilnej wersji Kali Linuxa.

~fc