top of page

Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
Zdjęcie autoraPiotr Kośka

OpenSSL wydaje łatę dla 2 nowych luk o wysokim stopniu ważności

Zaktualizowano: 3 lis 2022



Projekt OpenSSL wdrożył poprawki, które zawierają dwie bardzo poważne wady w szeroko używanej bibliotece kryptograficznej, które mogą skutkować odmową usługi (DoS) i zdalnym wykonaniem kodu.


Problemy, śledzone jako CVE-2022-3602 i CVE-2022-3786 , zostały opisane jako luki w zabezpieczeniach związane z przepełnieniem bufora, które mogą zostać wyzwolone podczas weryfikacji certyfikatu X.509 poprzez podanie specjalnie spreparowanego adresu e-mail.


„W kliencie TLS można to wywołać, łącząc się ze złośliwym serwerem” — powiedział OpenSSL w poradniku dla CVE-2022-3786. „Na serwerze TLS może to zostać wywołane, jeśli serwer zażąda uwierzytelnienia klienta, a złośliwy klient nawiąże połączenie”.


OpenSSL to implementacja open source protokołów SSL i TLS używanych do bezpiecznej komunikacji i jest wypiekana w kilku systemach operacyjnych i szerokiej gamie oprogramowania.


Wersje 3.0.0 do 3.0.6 biblioteki są dotknięte nowymi błędami, które zostały usunięte w wersji 3.0.7. Warto zauważyć, że powszechnie wdrażane wersje OpenSSL 1.x nie są podatne na ataki.


Według danych udostępnionych przez Censys około 7062 hostów korzystało z podatnej wersji OpenSSL na dzień 30 października 2022 r., przy czym większość z nich znajduje się w USA, Niemczech, Japonii, Chinach, Czechach, Wielkiej Brytanii, Francji, Rosji, Kanada i Holandia.


Chociaż CVE-2022-3602 był początkowo traktowany jako podatność krytyczna, jego istotność została obniżona do wysokiego, powołując się na zabezpieczenia przed przepełnieniem stosu w nowoczesnych platformach. Badacze bezpieczeństwa Polar Bear i Viktor Dukhovni zostali uznani za zgłoszenie CVE-2022-3602 i CVE-2022-3786 w dniach 17 i 18 października 2022 r.





Projekt OpenSSL zauważył ponadto, że błędy zostały wprowadzone w OpenSSL 3.0.0 jako część funkcji dekodowania kodu punycode , która jest obecnie używana do przetwarzania ograniczeń nazwy adresu e-mail w certyfikatach X.509.


Pomimo zmiany istotności, OpenSSL powiedział, że uważa „te problemy za poważne luki w zabezpieczeniach, a dotkniętych nimi użytkowników zachęca się do jak najszybszej aktualizacji”.


Wersja 3.0, bieżąca wersja OpenSSL, jest dołączona do systemów operacyjnych Linux, takich jak między innymi Ubuntu 22.04 LTS, CentOS, macOS Ventura i Fedora 36. Dotyczy to również obrazów kontenerów utworzonych przy użyciu wersji systemu Linux, których dotyczy problem.


Zgodnie z poradnikiem opublikowanym przez Docker, około 1000 repozytoriów obrazów może być dotkniętych różnymi obrazami Docker Official Images i Docker Verified Publisher.


Ostatnia krytyczna luka usunięta przez OpenSSL miała miejsce we wrześniu 2016 r., kiedy zamknęła CVE-2016-6309 , błąd typu use-after-free, który mógł spowodować awarię lub wykonanie dowolnego kodu.


Na pakiet oprogramowania OpenSSL w największym stopniu wpłynął Heartbleed ( CVE-2014-0160 ), poważny problem z obsługą pamięci w implementacji rozszerzenia TLS/DTLS heartbeat, umożliwiający atakującym odczytywanie części pamięci serwera docelowego.


„Krytyczna luka w zabezpieczeniach biblioteki oprogramowania, takiej jak OpenSSL, która jest tak szeroko stosowana i tak fundamentalna dla bezpieczeństwa danych w Internecie, to taka, której żadna organizacja nie może przeoczyć” – powiedział SentinelOne .


Identyfikowanie podatnych wersji OpenSSL

Ustalenie, czy host jest podatny na ten niewydany błąd, jest nadal niejasne, ponieważ nie znamy wszystkich szczegółów. Możemy jednak przyjrzeć się usługom w Internecie, które reklamują konkretną wersję OpenSSL, z której korzystają, aby uzyskać ogólne pojęcie o tym, co jest podatne na ataki. Obecnie nie znamy żadnej techniki poza sprawdzaniem nagłówków HTTP w celu określenia dokładnej używanej wersji OpenSSL, ale wciąż badamy alternatywy. Oznacza to, że chociaż widzimy wiele potencjalnie podatnych serwerów, nie mamy wglądu w nie wszystkie, a statystyki w tym poście to dolne granice tego, co istnieje.


Na szczęście niektóre serwery internetowe, takie jak Apache, oferują informacje, które dają nam wgląd w to, jakie konkretne wersje OpenSSL są używane. Na przykład w poniższym wyniku widzimy, że Apache dodał wszystkie załadowane moduły do ​​danych wyjściowych nagłówka „Server”. Jedną z nich jest wersja OpenSSL, z którą skompilowano moduł mod_ssl:

$ curl -vvv https://127.0.0.1/
* Próbuję 127.0.0.1:443...
* Podłączony do 127.0.0.1 (127.0.0.1) portu 443 (#0)
> POBIERZ / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: zwijanie/7.81.0
> Zaakceptuj: */*
>
< HTTP/1.1 200 OK
< Data: poniedziałek, 31 października 2022 21:27:29 GMT
< Serwer: Apache/2.4.53 (Win64) OpenSSL/1.1.1n PHP/8.0.18
< Zawartość-Długość: 1436
< Content-Type: text/html;charset=UTF-8

Linki:

143 wyświetlenia0 komentarzy

Ostatnie posty

Zobacz wszystkie

Comments


Śledź nasze wpisy w social media

  • Instagram
  • Facebook
  • Twitter
  • LinkedIn
  • YouTube

Poznaj terraform jedno z najepszych narzedzi do zarządzania infrastrukturą w kodzie (IaC) - w kursie tym przeprowadzam Cię przez proces instalacji i konfiguracji tego narzędzia.

bottom of page