OpenSSL łata lukę wysokiej wagi mogącą prowadzić do RCE (CVE-2025-15467). Co trzeba wiedzieć i zrobić - Security Bez Tabu

OpenSSL łata lukę wysokiej wagi mogącą prowadzić do RCE (CVE-2025-15467). Co trzeba wiedzieć i zrobić

Wprowadzenie do problemu / definicja luki

Pod koniec stycznia 2026 r. projekt OpenSSL opublikował aktualizacje bezpieczeństwa usuwające łącznie 12 podatności, w tym jedną oznaczoną jako High – CVE-2025-15467 – która w określonych warunkach może prowadzić do remote code execution (RCE).

Kluczowe jest to, że nie mówimy o “zwykłym TLS do HTTPS” w oderwaniu od reszty świata, tylko o podatnej ścieżce w parsowaniu CMS/PKCS#7, w szczególności struktur CMS AuthEnvelopedData korzystających z AEAD (np. AES-GCM). Jeśli Twoje środowisko przyjmuje lub przetwarza taki format z niezaufanego źródła (bramki S/MIME, systemy PKI/CA, import certyfikatów, workflow dokumentów podpisanych/szyfrowanych), temat robi się pilny.

W skrócie

  • CVE: CVE-2025-15467 (High) – stack buffer overflow w obsłudze CMS AuthEnvelopedData przy AEAD.
  • Skutek: crash/DoS, a potencjalnie RCE (zależnie od platformy i mitigacji kompilatora/systemu).
  • Warunek wejścia: aplikacja/usługa parsuje niezaufane CMS/PKCS#7 z AEAD; overflow zachodzi przed weryfikacją integralności/tagu.
  • Wersje podatne (gałęzie 3.x):
    • 3.6.0 → przed 3.6.1
    • 3.5.0 → przed 3.5.5
    • 3.4.0 → przed 3.4.4
    • 3.3.0 → przed 3.3.6
    • 3.0.0 → przed 3.0.19
  • Nie dotyczy: OpenSSL 1.1.1 i 1.0.2 (wprost oznaczone jako niepodatne).
  • FIPS: moduły FIPS dla serii 3.x nie są dotknięte, bo implementacja CMS jest poza granicą modułu.
  • Kontekst wydania: w tym samym pakiecie łatek jest też podatność moderate (CVE-2025-11187) i 10 low.

Kontekst / historia / powiązania

Informację o wydaniu łatek opisał m.in. SecurityWeek, podkreślając, że wszystkie 12 podatności zostały odkryte przez jedną firmę (Aisle), przy użyciu autonomicznego analizatora.

Datadog Security Labs zwraca uwagę na jeszcze jeden aspekt: OpenSSL rzadko nadaje “high” podatnościom potencjalnie prowadzącym do RCE, a to wydanie jest zauważalne także z perspektywy klas wejścia danych (CMS/PKCS#12), które występują w realnych pipeline’ach bezpieczeństwa (poczta, PKI, importy/eksporty).

Analiza techniczna / szczegóły luki

Co dokładnie się psuje?

CVE-2025-15467 to przepełnienie bufora na stosie podczas parsowania parametrów ASN.1 dla AEAD w strukturach CMS AuthEnvelopedData. W praktyce problem dotyczy pola IV (Initialization Vector): zakodowana w ASN.1 długość IV jest kopiowana do bufora o stałym rozmiarze bez wystarczającej walidacji, co pozwala doprowadzić do zapisu poza buforem (out-of-bounds write).

Dlaczego “pre-auth” ma znaczenie?

Overflow występuje przed weryfikacją tagu uwierzytelniającego/integrowości, więc atakujący nie musi posiadać poprawnych kluczy ani generować poprawnej kryptograficznie wiadomości, aby “trafić” w podatną ścieżkę. To podnosi realność ataku wszędzie tam, gdzie parser może zetknąć się z danymi od strony napastnika (np. inbound e-mail, upload pliku, integracje B2B).

RCE vs DoS

OpenSSL i NVD opisują skutki jako DoS (najbardziej typowy) oraz potencjalne RCE, zależne od platformy i mitigacji (ASLR, stack canaries, CET, hardening kompilacji, układ stosu itp.). To klasyczny przypadek: błąd pamięci daje prymityw zapisu na stosie, ale droga do stabilnego RCE bywa różna w zależności od środowiska uruchomieniowego.

Praktyczne konsekwencje / ryzyko

Kto jest najbardziej narażony?

Najwyższe ryzyko mają systemy, które:

  • automatycznie przetwarzają niezaufane CMS/PKCS#7 (np. bramki S/MIME, systemy DLP/MTA z funkcjami dekryptażu/analizy, integratory EDI/archiwizacji zabezpieczonej wiadomości),
  • oferują import materiału kryptograficznego/struktur (workflow certyfikatów, PKI tooling),
  • mają bibliotekę OpenSSL 3.x jako zależność i nie mają pełnej kontroli nad formatem danych wejściowych.

Jeśli OpenSSL jest używany głównie do handshake TLS, a aplikacja nie dotyka CMS/PKCS#7 z niezaufanych źródeł, osiągalność podatnej ścieżki bywa ograniczona. Datadog wprost sugeruje takie rozróżnienie w ocenie ekspozycji.

Wpływ na dystrybucje i pakiety systemowe

Dystrybucje publikują własne biuletyny i backporty. Przykładowo Ubuntu w swoim USN opisuje CVE-2025-15467 jako błąd prowadzący do crash/DoS przy niepoprawnym parsowaniu CMS AuthEnvelopedData. To ważne, bo w praktyce “wersja OpenSSL” w systemie często oznacza “wersję pakietu distro”, a nie upstream tarball.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję (reachability), nie tylko wersję
  • Sprawdź, czy w Twoim środowisku istnieje komponent parsujący CMS/PKCS#7 / S/MIME AuthEnvelopedData z danych od użytkownika/Internetu (MTA, gateway, usługi importu, API upload).
  1. Zaktualizuj do wersji naprawionych
    Minimalne wersje naprawione dla gałęzi 3.x (wg OpenSSL):
  • 3.0.19, 3.3.6, 3.4.4, 3.5.5, 3.6.1
    W praktyce w środowiskach produkcyjnych często aktualizujesz pakiet systemowy (np. przez apt/yum/zypper) – wtedy kieruj się biuletynem dostawcy (np. USN w Ubuntu).
  1. Uważaj na “własny OpenSSL” w runtime’ach i kontenerach
    Niektóre środowiska mogą dostarczać własne buildy OpenSSL (np. część runtime’ów/obrazów). Datadog podkreśla, że samo podbicie pakietu systemowego nie zawsze wystarczy – czasem trzeba zaktualizować cały runtime/artefakt.
  2. Mitigacje tymczasowe (jeśli nie możesz patchować natychmiast)
  • Ogranicz/wyłącz przetwarzanie niezaufanego S/MIME/CMS AuthEnvelopedData tam, gdzie to możliwe (polityki gateway, izolacja pipeline’u, sandbox).
  • Rozważ uruchamianie parserów w izolacji (separacja procesu, seccomp/AppArmor/SELinux, ograniczenia uprawnień) – to nie naprawia błędu, ale redukuje blast radius w scenariuszu RCE. (To jest dobra praktyka ogólna przy parserach danych binarnych.)
  1. Monitoring i IR
    Na dziś opisy źródłowe skupiają się na aktualizacji i ocenie ekspozycji; nie wynika z nich jednoznacznie, że istnieje masowa eksploatacja “in the wild”. Mimo to, traktuj to jak podatność parsera: monitoruj crashe procesów (segfault), wzrost błędów w usługach mail/PKI oraz nietypowe wejścia CMS/PKCS#7.

Różnice / porównania z innymi przypadkami

  • Nie “kolejny Heartbleed”: wektor jest znacznie bardziej specyficzny – dotyczy parsowania CMS AuthEnvelopedData z AEAD, a nie każdego połączenia TLS. To dobra wiadomość dla typowych serwerów WWW, ale zła dla systemów, które masowo obrabiają S/MIME/CMS.
  • Waga “High” i potencjalne RCE: Datadog zauważa, że OpenSSL rzadko klasyfikuje potencjalne RCE aż tak wysoko, co sugeruje ostrożność w bagatelizowaniu tego jako “tylko DoS”.
  • Podobieństwo klasowe: to klasyczny błąd pamięci (CWE-787 / out-of-bounds write) – a więc kategoria, która historycznie bywa trudna w ocenie “czy to na pewno RCE”, bo dużo zależy od kompilacji i mitigacji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-15467 to High w OpenSSL 3.x: przepełnienie stosu w parsowaniu CMS AuthEnvelopedData (AEAD).
  • Realny wpływ zależy od tego, czy Twoja aplikacja parsuje niezaufane CMS/PKCS#7 – w takich środowiskach priorytet patchowania powinien być wysoki.
  • Aktualizuj do: 3.0.19 / 3.3.6 / 3.4.4 / 3.5.5 / 3.6.1 (lub odpowiednich backportów dystrybucji).
  • Jeśli nie możesz patchować natychmiast: ogranicz powierzchnię (S/MIME/CMS), izoluj parsery, wzmocnij monitoring crashy – ale traktuj to jako rozwiązania przejściowe.

Źródła / bibliografia

  1. OpenSSL Library – Vulnerabilities 3.4 (CVE-2025-15467; wersje podatne i naprawione, opis podatności). (openssl-library.org)
  2. OpenSSL Library – Vulnerabilities (opis wpływu i scenariuszy CMS/PKCS#7). (openssl-library.org)
  3. NVD – CVE-2025-15467 (opis techniczny, CWE-787, referencje). (NVD)
  4. Datadog Security Labs – analiza styczniowego wydania OpenSSL 2026 (kontekst, reachability, wskazówki oceny). (securitylabs.datadoghq.com)
  5. SecurityWeek – informacja o wydaniu i kontekście (12 podatności, CVE-2025-15467 jako High). (SecurityWeek)
  6. Ubuntu Security Notice USN-7980-1 (perspektywa dystrybucji / pakietów). (Ubuntu)