Komputery DELL, HP i Lenovo z lukami OpenSSL w oprogramowaniu sprzętowym

O które luki w OpenSSL chodzi?

Na początku tego miesiąca CISA opublikowała poradnik dotyczący ostatnich poważnych problemów bezpieczeństwa OpenSSL (CVE-2022-3602 i CVE-2022-3786). Pisaliśmy o tym także na Kapitanie.

Luki w zabezpieczeniach CVE-2022-3602 i CVE-2022-3786 związane są z niepowodzeniem weryfikacji certyfikatu x.509, co może prowadzić do przepełnienia bufora stosu.

W rzeczywistości nie dotyczy to starszych wersji, takich jak OpenSSL 1.0.2 i 1.1.1. Wcześniejsze wersje również pozostają nienaruszone, ponieważ zagrożony kod został wprowadzony po raz pierwszy w OpenSSL 3.0.0.

DELL, HP i Lenovo na celowniku

Analitycy cyberbezpieczeństwa z Binarly odkryli niedawno, że ciągle używane są przestarzałe wersje biblioteki kryptograficznej OpenSSL w oprogramowaniach urządzeń produkowanych przez Dell, HP i Lenovo. Zawierają one wersje, które stanowią zagrożenie dla łańcucha dostaw ze względu na ich nieaktualność. Może to ułatwiać cyberprzestępcom przejęcie kontroli nad komputerem.

W czym tkwi problem?

Od niedawna branża technologiczna dyskutuje na temat wykorzystania tzw. listy software bill of materials (w skrócie SBOM) w celu przeciwdziałania zagrożeniom bezpieczeństwa łańcucha dostaw. Aby wdrożyć praktyki bezpieczeństwa, musi istnieć większa przejrzystość zależności oprogramowania. Wcześniej każde oprogramowanie było dostarczane jako czarna skrzynka bez jakichkolwiek informacji związanych z jego zależnościami czy komponentami stron trzecich. Oprogramowanie układowe było w dużej mierze postrzegane w ten sam sposób.

Implementacją oprogramowania układowego (UEFI) typu open source jest zestaw EFI Development Kit, znany również jako EDK, który także jest EFI. W tym sensie system operacyjny działa jako interfejs między oprogramowaniem wbudowanym w sprzęt urządzenia a systemem operacyjnym.

„W środowisku programistycznym oprogramowania układowego wbudowany jest pakiet kryptograficzny o nazwie CryptoPkg, który w rezultacie wykorzystuje usługi z projektu OpenSSL do świadczenia usług kryptograficznych w oprogramowaniu układowym” – dowiadujemy się od badaczy Binarly.

Podczas analizy stwierdzono, że kilka wersji OpenSSL jest częścią obrazów oprogramowania układowego powiązanych z urządzeniami korporacyjnymi Lenovo Thinkpad.

Poniżej podajemy wszystkie trzy wersje OpenSSL:

• 0.9.8zb
• 1.0.0a
• 1.0.2j

W oprogramowaniu układowym znajduje się jeden moduł oparty na OpenSSL w wersji 0.9.8zb, która została wydana 4 sierpnia 2014 r., a znana jest jako InfineonTpmUpdateDxe. Warstwa SSL (Secure Socket Layer) i Transport Layer Security (TLS) to protokoły typu open source, które są implementowane przez OpenSSL.

„Repozytorium Github EDKII jest regularnie aktualizowane, a społeczność programistów rozwiązuje problemy związane z bezpieczeństwem. Przeanalizowano wiele obrazów oprogramowania układowego używanych przez wyżej wymienionych producentów, aby ustalić, czy problem występuje w ich urządzeniach” – piszą badacze z Binarly.

Często oprogramowanie układowe można postrzegać jako pojedynczy punkt awarii we wszystkich warstwach łańcucha dostaw, a także urządzenia użytkownika końcowego, na końcu łańcucha.

Ostatnio w „Digital Defense Report 2022” Microsoft zwrócił uwagę na następujący kluczowy punkt:

„W 32% zbadanych obrazów oprogramowania sprzętowego zidentyfikowano co najmniej 10 krytycznych luk w zabezpieczeniach”.

Szacuje się, że co najmniej dwie lub trzy luki w oprogramowaniu układowym występują w około 20% aktualizacji.

Latem 2021 roku korporacyjne urządzenia Lenovo korzystały z najnowszej dostępnej wówczas w Internecie wersji protokołu OpenSSL.

Wnioski z badania

Wiele pakietów oprogramowania sprzętowego Lenovo i Dell nadal korzysta ze starszej wersji (0.9.8l), która została wydana 5 listopada 2009 r. i ma już ponad dekadę.

Podobnie kod oprogramowania układowego HP zależny był od 10-letniej wersji biblioteki (0.9.8w) i ta sama wciąż była używana przez wielu innych producentów.

Podsumowanie

Dziedzina analizy kodu binarnego jest jedną z najbardziej złożonych i nie ma łatwego rozwiązania. Aby sposoby na zapewnienie bezpieczeństwa łańcucha dostaw oparte na SBOM odniosły sukces w dzisiejszym świecie, branża musi zacząć myśleć o nich inaczej.

Jeśli chodzi o kod strony trzeciej, który jest zawarty w kodzie aplikacji, lista zależności ciągle zawodzi. W przypadku niepowodzeń SBOM podejście „ufaj, ale weryfikuj” jest najlepszym sposobem na zmniejszenie ryzyka w łańcuchu dostaw i prawdopodobieństwa niepowodzeń SBOM.