Luka w OpenSSH umożliwiająca zdalne wykonanie kodu z uprawnieniami roota na serwerach z Glibc

Firma Qualys zidentyfikowała krytyczną lukę w zabezpieczeniach (CVE-2024-6387) w systemie OpenSSH, która może umożliwić zdalne wykonywanie kodu z uprawnieniami roota bez uwierzytelniania. Luka w zabezpieczeniach o nazwie kodowej regreSSHion dotyczy domyślnej konfiguracji począwszy od wersji OpenSSH 8.5 w systemach ze standardową biblioteką Glibc.

Atak został zademonstrowany na 32-bitowym systemie Glibc z włączoną funkcją ASLR (randomizacja przestrzeni adresowej). Skuteczny atak w warunkach laboratoryjnych wymagał 6-8 godzin, w trakcie których serwer Połączenia były nawiązywane nieprzerwanie z maksymalną szybkością dozwoloną w konfiguracji sshd. Atak jest prostszy i zajmuje mniej czasu w systemach bez ASLR lub w dystrybucjach korzystających ze zmodyfikowanego OpenSSH, który wyłącza ponowną randomizację ASLR dla każdego połączenia. Działający prototyp exploita nie został publicznie opublikowany do czasu powszechnego załatania luki, jednak wystarczająco szczegółowy opis luki jest dostępny, co sprawia, że ​​pojawienie się exploitów firm trzecich jest kwestią czasu.

Nie można wykluczyć możliwości ataku na systemy 64-bitowe, ale nie ma jeszcze gotowego sposobu na wykorzystanie tej luki w zabezpieczeniach dla takich systemów. Oczekuje się, że atak na systemy 64-bitowe potrwa znacznie dłużej, jednak nie dłużej niż tydzień. Problem ten nie dotyczy systemu OpenSSH w systemie OpenBSD, ponieważ od 2001 r. w systemie funkcjonuje mechanizm ochrony blokujący tego typu ataki. W pozostałych systemach bazujących na bibliotekach standardowych innych niż Glibc teoretycznie możliwe jest dostosowanie metody do przeprowadzenia ataku (kwestia ta nie była jeszcze badana w przypadku Qualys).

Luka została naprawiona w łatce OpenSSH 9.8, wydanej dzisiaj. Aktualizacje pakietów dla dystrybucji można śledzić na następujących stronach: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch i FreeBSD. Aby obejść lukę, można ustawić parametr „LoginGraceTime=0” w pliku sshd_config. Wyłączenie limitu czasu ułatwi atak typu „odmowa usługi” w przypadku nawiązania dużej liczby połączeń przekraczających limity określone parametrem MaxStartups.
Jednym z objawów próby ataku jest pojawienie się w dzienniku dużej liczby wpisów „Przekroczono limit czasu przed uwierzytelnieniem”.

Luka w zabezpieczeniach jest spowodowana regresywną zmianą wprowadzoną w wersji OpenSSH 8.5, która wprowadza sytuację wyścigu w kodzie obsługi sygnałów w sshd. Regresja spowodowała zakończenie ochrony przed starą luką w zabezpieczeniach CVE-2006-5051, która występowała przed wersją OpenSSH 4.4 (2006) i miała charakter teoretyczny.
W trakcie opracowywania OpenSSH 8.5 blok „#ifdef DO_LOG_SAFE_IN_SIGHAND” został przez pomyłkę usunięty z funkcji sigdie(), która jest bezpośrednio wywoływana z procedury obsługi sygnału SIGALRM.

Procedura obsługi SIGALRM jest wywoływana w sshd asynchronicznie, jeśli klient nie uwierzytelni się w ramach limitu czasu połączenia (LoginGraceTime, domyślnie 120 s). Atak opiera się na fakcie, że obsługa sygnału wywołuje funkcje, które nie są bezpieczne w przypadku asynchronicznej obsługi sygnału, np. syslog(). Funkcja syslog() w bibliotece Glibc nie jest przeznaczona do użytku w asynchronicznym wykonywaniu procedur obsługi sygnałów, ponieważ wywołuje ona funkcje malloc() i free(). Wyzwolenie sygnału SIGALRM, który przerywa działanie określonego kodu w sshd, może doprowadzić do naruszenia stanu wykonania, a zadanie exploita sprowadza się do stworzenia warunków do przerwania niezbędnego kodu w wymaganym momencie jego wykonania. Luka ta nie dotyczy systemu OpenBSD, ponieważ zamiast funkcji syslog() funkcja obsługi sygnału SIGALRM wywołuje funkcję syslog_r(), która została specjalnie zaprojektowana do działania asynchronicznego.

Źródło: opennet.ru

Kup niezawodny hosting dla stron z ochroną DDoS, serwery VPS VDS 🔥 Kup niezawodny hosting stron internetowych z ochroną DDoS, serwery VPS VDS | ProHoster