Zespół stojący za szeroko używaną biblioteką kryptograficzną typu open source OpenSSL załatał dwie luki w usłudze, które wcześniej wykonał w nieco nietypowy sposób wstępne ostrzeganie zespołów ds. bezpieczeństwa o.
OpenSSL wydał zalecenie pod koniec października, mówiąc, że przygotowuje się do załatania krytycznej luki – która byłaby pierwszą krytyczną luką ujawnioną w bibliotece od Heartbleed.
Wspomnienia Heartbleed sprawiły, że wiele osób podejrzewało problem o podobnym znaczeniu, ale w takim przypadku ujawnienie przeszło bez wywołania powszechnej paniki, a początkowy krytyczny stan luki został obniżony do wysokiego.
Aktualizacja z OpenSSL 3.0.6 na OpenSSL 3.0.7 naprawia dwie różne luki przepełnienia bufora w Kod Puny funkcje dekodowania. Te luki są śledzone odpowiednio jako CVE-2022-3602 i CVE-2022-3786.
CVE-2022-3602 umożliwia wyzwolenie przepełnienia bufora podczas analizowania certyfikatu X.509 TLS (Transport Layer Security) po jego zweryfikowaniu. Jest to spowodowane sposobem przetwarzania kodu Punycode podczas sprawdzania certyfikatów.
Może zostać wykorzystany, jeśli atakujący z powodzeniem stworzy złośliwy adres e-mail w celu przepełnienia czterech kontrolowanych przez atakującego bajtów na stosie, w związku z czym atakujący musi mieć dostęp do zaufanego certyfikatu, aby przeprowadzić udany atak. Pomyślnie wykorzystany może doprowadzić do awarii powodującej odmowę usługi i potencjalnie do zdalnego wykonania kodu (RCE).
CVE-2022-3786 różni się nieco tym, że atakujący może go wykorzystać tylko poprzez stworzenie złośliwego adresu e-mail w celu przepełnienia dowolnej liczby bajtów zawierających kropkę. Pomyślnie wykorzystany, może doprowadzić do awarii powodującej odmowę usługi.
Yotam Perkal, dyrektor ds. badań podatności w Rezilion, specjalista od naprawy luk w oprogramowaniu, powiedział: „Biorąc pod uwagę wszystkie czynniki, wydaje się, że wykorzystanie tych luk w środowisku naturalnym w celu wykonania kodu jest mało prawdopodobne. To powiedziawszy, eksploatacja jest możliwa, dlatego zaleca się jak najszybsze zidentyfikowanie i załatanie wrażliwych zasobów.
Szybki7 dyrektor ds. badań, Tod Beardsley, dodał: „Te ujawnienia luk w zabezpieczeniach OpenSSL – i poprawki – nie są na szczęście tak złe, jak wszystkie spekulacje mogłyby nas sądzić.
„Dostawcy i operatorzy powinni zaktualizować swoją zależność od OpenSSL do wersji 3.0.7, gdy jest to wykonalne, przestrzegając normalnych procedur kontroli zmian i biorąc pod uwagę specyficzny profil ryzyka dla tych organizacji. Dla większości ludzi nie jest to tak naprawdę sytuacja awaryjna, której wszyscy się spodziewaliśmy”.
Te, które powinny przyspieszyć aktualizację, to najprawdopodobniej te, które korzystają z implementacji OpenSSL, które zostały skonfigurowane do wzajemnego uwierzytelniania – gdzie zarówno klient, jak i serwer dostarczają certyfikaty dostarczone przez OpenSSL do uwierzytelniania, wyjaśnił Beardsley.
Cykod główny badacz bezpieczeństwa Alex Ilgayev powiedział, że pomimo obniżenia wersji, wiele organizacji nadal powinno traktować te luki jako krytyczne. „OpenSSL podaje jako powód obniżenia wersji stosowanie zabezpieczeń przepełnienia stosu w nowoczesnym oprogramowaniu. Jednak wiele krytycznych aplikacji nie jest nowoczesnych, takich jak te, które obsługują bankomaty, narzędzia i inną infrastrukturę o znaczeniu krytycznym” – powiedział.
Ilgayev wyjaśnił, że ostatecznie największym wnioskiem z tego incydentu dla specjalistów ds. bezpieczeństwa jest konieczność zachowania kompleksowości i utrzymania zestawienie komponentów oprogramowania (SBOM). „Łata OpenSSL 3.0.7 demonstruje oba te punkty ze względu na wszechobecność OpenSSL”, powiedział.
„Organizacje bez SBOM starają się zidentyfikować podatne na ataki użycie OpenSSL od zeszłotygodniowego ogłoszenia. Jest to kwestia priorytetyzacji, którą większość organizacji wydaje się być przygotowana do rozwiązania. Jednak uzyskanie wzajemnego poparcia w celu nadania priorytetu wszystkim, co nie jest natychmiastowo pilne, pozostaje wyzwaniem dla większości zespołów ds. Bezpieczeństwa aplikacji”.
Jednak profesjonaliści ds. bezpieczeństwa dobrze zrobią, jeśli rozważą wyjście poza SBOM i rozważenie podejścia do wykazu materiałów (PBOM), ponieważ wszechobecność OpenSSL oznacza, że jest on szeroko stosowany nie tylko w kodzie źródłowym aplikacji, ale także w infrastrukturze używanej do jej tworzenia i dostarczania. Ilgajew.
Modele PBO rozszerzają koncepcję SBOM, aby lepiej odzwierciedlać sposób, w jaki zależności są obecnie używane, uwzględniając kod innej firmy, który może prowadzić do naruszenia, nawet jeśli nie jest obecny w samej aplikacji, i gdzie zależności są faktycznie wdrażane w środowiskach wykonawczych.
„Powinniśmy poważnie potraktować to ćwiczenie, aby wygrzebać dziury i znaleźć słabości w naszych SBOM i PBOM, ponieważ najnowsza historia – Heartbleed, Struts, Jackson-databind, LodDash Log4Shell, Log4Text itd. – pokazuje, że zawsze istnieje inna poważna zależność tuż za horyzontem. ” powiedział Ilgayev.