26 października twórcy projektu OpenSSL poinformowali o istnieniu luki w swojej niemal wszechobecnej bibliotece do szyfrowania komunikacji w Internecie. Zapowiedzieli, iż aktualizacja zostanie wydana pięć dni później wraz z publikacją szczegółów dotyczących podatności. Dziurawe są wszystkie wersje OpenSSL od 3.0 w górę, a sama podatność miała zostać sklasyfikowana jako krytyczna. Oznacza to, iż błąd jest bardzo łatwy do wykorzystania i prawdopodobnie skutkuje możliwością zdalnego wykonania kodu na serwerze lub przejęciem kluczy prywatnych. Zaleca się jak najszybsze załatanie systemów, aplikacji i usług korzystających z OpenSSL.
Opis podatności
1 listopada na oficjalną stronę projektu OpenSSL trafiła szczegółowa informacja i opis techniczny luki, która otrzymała numer CVE-2022-3602. Ostatecznie poziom ryzyka podatności został przez OpenSSL określony jako HIGH (wysoki), a nie krytyczny, z powodu szeroko opisanych okoliczności łagodzących, jak na przykład wbudowana w kompilatory ochrona przed przepełnieniem stosu. Możliwe, iż to tylko psychologiczna zagrywka w celu zmniejszenia paniki w Internecie.
Podatność polega na wyzwoleniu przepełnienia bufora podczas weryfikacji certyfikatu X.509, w szczególności podczas sprawdzania ograniczeń nazw. Należy zauważyć, iż dzieje się tak po weryfikacji podpisu łańcucha certyfikatów i wymaga to podpisania przez urząd certyfikacji złośliwego certyfikatu lub kontynuowania weryfikacji certyfikatu przez aplikację. Atakujący może stworzyć złośliwy adres e-mail, aby przepełnić cztery kontrolowane przez niego bajty na stosie. Przepełnienie pamięci może spowodować awarię (powodującą odmowę usługi) lub potencjalnie zdalne wykonanie kodu.
Na szczęście wiele platform implementuje zabezpieczenia przed przepełnieniem stosu, które zmniejszają ryzyko zdalnego wykonania kodu. Ryzyko to może być dodatkowo ograniczone w oparciu o układ stosu dla dowolnej platformy/kompilatora. Tylko dlatego ryzyko wykonania podatności nie jest krytyczne.
W kliencie TLS lukę można wykonać, łącząc się ze złośliwym serwerem. Na serwerze TLS może zostać wykorzystana, jeżeli zażąda on uwierzytelnienia klienta, a połączenie nawiąże złośliwy klient.
Potencjalnie ogromny problem
Główni dostawcy systemów operacyjnych, wydawcy oprogramowania, firmy technologiczne oraz dostawcy poczty e-mail, którzy zintegrowali OpenSSL ze swoimi produktami i usługami, prawdopodobnie udostępnią zaktualizowane wersje swoich technologii w najbliższych dniach. przez cały czas pozostawi to jednak potencjalne miliony innych – w tym organy rządowe, firmy prywatne, usługodawców, producentów urządzeń sieciowych i niezliczonych operatorów witryn internetowych – ze zbliżającym się terminem znalezienia i załatania luki OpenSSL, zanim cyberprzestępcy zaczną ją wykorzystywać.
Sam OpenSSL definiuje lukę wysoką jako problemy obarczone mniejszym ryzykiem niż krytyczne, być może ze względu na wpływ na mniej popularne konfiguracje lub takie, których wykorzystanie jest mniej prawdopodobne.
Wersja 3.0, aktualna wersja OpenSSL, jest używana w wielu obecnych systemach operacyjnych, takich jak Ubuntu 22.04 LTS oraz MacOS Mavericks i Ventura. Organizacje mogą spodziewać się szybkiego otrzymania łat dla systemu Linux – choćby dziś. Jednak firmy powinny się już przygotowywać na maksymalne rozeznanie swoich zasobów, aby dowiedzieć się, które systemy korzystają z OpenSSL 3.0.
Brian Fox, współzałożyciel i CTO w Sonatype, mówił, iż zanim OpenSSL Project ujawni błąd we wtorek, organizacje muszą określić, czy używają wersji podatnej na ataki w dowolnym miejscu swojego portfolio technologicznego, które aplikacje z niej korzystają i jak długo zajęłoby im naprawienie problemu.
„Potencjalny zasięg jest zawsze najważniejszym elementem każdej poważnej wady” — zauważa Fox. „W tym przypadku największym wyzwaniem związanym z aktualizacją OpenSSL jest fakt, iż często to użycie jest osadzone w innych urządzeniach”. Dodaje, iż w takich przypadkach może być trudno ocenić ryzyko bez konsultacji dostawcy danej technologii. Wszystko, co bezpiecznie komunikuje się z Internetem, potencjalnie może mieć wbudowane OpenSSL. I to nie tylko oprogramowanie, ale także sprzęt. Wcześniejsze powiadomienie o podatności przez OpenSSL powinno dać organizacjom czas na przygotowanie się.
Podsumowanie
Wiele będzie zależeć od tego, jak dostawcy produktów z wbudowanymi wersjami OpenSSL podatnymi na ataki zareagują na ujawnienie. Wydanie nowej wersji 3.0.7 projektu OpenSSL we wtorek to dopiero pierwszy krok. Cały ekosystem aplikacji zbudowanych z OpenSSL będzie również musiał aktualizować swój kod, opublikować własne aktualizacje, a organizacje będą musiały je zastosować.
Mike Parkin, starszy inżynier techniczny w Vulcan Cyber, mówi, iż bez dowodów na aktywność exploitów i powiązanych wskaźników kompromitacji najlepiej jest, aby organizacje przestrzegały normalnego procesu zarządzania zmianami, gdy nadchodzi znana aktualizacja. „Jeśli chodzi o bezpieczeństwo, warto położyć dodatkowy nacisk na systemy, które mogą zostać zaatakowane, jeżeli exploit pojawi się przed wypuszczeniem nowej wersji” – radzi. W ogłoszeniu OpenSSL Project nie ma wystarczających informacji, aby określić, ile pracy będzie wymagało wykonanie upgrade’u, ale jeżeli aktualizacja certyfikatów nie okaże się konieczna, akcja będzie prawdopodobnie prosta.
