Krytyczne luki RCE w OpenSSH. Łatajcie systemy!

Krótko o OpenSSH

OpenSSH to jedno z najlepszych i najpopularniejszych narzędzi łączności umożliwiających zdalne logowanie za pomocą protokołu SSH. Szyfruje cały ruch, dzięki czemu eliminuje podsłuchiwanie, przejmowanie połączeń i inne ataki. Ponadto zapewnia duży zestaw możliwości bezpiecznego tunelowania, kilka metod uwierzytelniania i zaawansowane opcje konfiguracji. Jest używane jako pierwsza i jedyna linia obrony milionów serwerów w całym Internecie, dlatego jego bezpieczeństwo jest kluczowe. Równocześnie jest to jednak powód, dla którego OpenSSH stał się celem o dużej wartości dla potencjalnych atakujących.

Podatności w OpenSSH

Bezpieczeństwo OpenSSH wysunęło się na pierwszy plan dwa miesiące temu wraz z odkryciem budzącej strach luki dnia zerowego w xz-utils, atakującej plik binarny OpenSSH w celu uzyskania dostępu backdoorem do systemów operacyjnych opartych na Linuksie.

Problem z OpenSSH powrócił z luką typu zero-day, która okazuje się ogromną luką umożliwiającą zdalne wykonanie kodu na serwerach OpenSSH. Firma Qualys, która znalazła wady dzięki swoim badaniom, nadała luce nazwę „RegreSSHion”.

Analizując dane z kilku źródeł, takich jak Shodan czy Censys, można zaobserwować, że na dzień publikacji tego artykułu istnieje prawie 7 milionów odsłoniętych instancji OpenSSH, które są potencjalnie podatne na RegresSSHion. Zapytanie w Shodan:

port:22 product:"OpenSSH"
version:8.5,8.5p1,8.6,8.6p1,8.7,8.7p1,8.8,8.8p1,8.9,8.9p1,9.0,9.0p1,9.1,9.1p1,9.2,9.2p1,9.3,9.3p1,9.4,9.4p1,9.5,9.5p1,9.6,9.6p1,9.7,9.7p1

Ciekawostką jest, że w chwili publikacji podatności przez firmę Qualys było ich aż 14 milionów!

CVE-2024-6387: wpływ na główny proces serwera OpenSSH

Luka potencjalnie umożliwia nieuwierzytelnione zdalne wykonanie kodu z uprawnieniami roota.

Wpływa na domyślną instalację OpenSSH i polega na skorzystaniu z sytuacji wyścigu w celu uzyskania zdalnego wykonania kodu. Mimo że udana eksploitacja regresSSHion ma poważny skutek (eskalacja uprawnień do root), pozom krytyczności podatności został oceniony jako wysoki z powodu dość skomplikowanego ataku. W celu osiągnięcia RCE konieczne jest wykonanie dużej liczby prób uwierzytelniania w długim czasie.

W kontekście tej luki, jeśli klientowi nie uda się uwierzytelnić w określonym czasie (LoginGraceTime), który domyślnie wynosi 120 sekund, uruchamiana jest procedura obsługi sygnału serwera, aby obsłużyć przekroczenie limitu czasu.

Luka CVE-2024-6409

Przy okazji omawiania luki CVE-2024-6387 warto wspomnieć o innej – CVE-2024-6409, wpływającej na proces podrzędny separacji uprawnień z ograniczonymi uprawnieniami, co dotyczy OpenSSH w wersjach 8.7 i 8.8.

• Sytuacja wyścigu w funkcji Grace_alarm_handler() stwarza możliwość zdalnego wykonania kodu w procesie potomnym privsep.
• Nowa luka ma mniejsze bezpośrednie skutki, ale nadal stwarza poważne ryzyko bezpieczeństwa.‍

Które systemy są podatne?

Luka dotyczy wielu wersji OpenSSH, w tym większości dystrybucji Linuksa, ponieważ są one domyślnie dostarczane z OpenSSH.

Jako że główną przyczyną luki jest regresja w kodzie OpenSSH, oryginalne CVE wpływa na bardzo stare wersje serwera OpenSSH, nie dotykając nowszych wersji (przed regresją).

 W dniu publikacji tego artykułu sytuacja prezentuje się następująco:

• Stara wersja luki (CVE-2006-5051) dotyczy wersji OpenSSH wcześniejszych niż OpenSSH 4.4/4.4p1 (2006-09-27) (chyba że zostały one załatane dla CVE-2006-5051 i CVE-2008-4109).
• Regresja luki została wprowadzona w wersji OpenSSH 8.5/8.5p1 (2021-03-03).
• Opiekunowie OpenSSH naprawili lukę w wersji OpenSSH 9.8/9.8p1(2024-07-01).

Łatajcie systemy!

Dostępna poprawka polega na usunięciu problematycznego kodu z procedury obsługi sygnału, zapewniając, że w tym kontekście wykonywane są tylko bezpieczne operacje.

Administratorzy powinni priorytetowo potraktować zastosowanie poprawek lub obejścia w celu ograniczenia luki wysokiego ryzyka na serwerach OpenSSH działających w systemach Linux opartych na glibc.

Dla systemów, w przypadku których nie możesz zastosować poprawki, jest dostępne obejście problemu poprzez: ‍

• ustawienie parametru „LoginGraceTime” na 0 w pliku konfiguracyjnym „/etc/ssh/sshd_config‍”
• oraz wykonanie restartu usługi za pomocą polecenia: „systemctl restart sshd”.

Zastosowanie poprawki stanowi skuteczne zabezpieczenie w przypadku obu opisanych wyżej luk.