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, iż 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żeli 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, iż 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
- 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).
- 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).
- 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, iż samo podbicie pakietu systemowego nie zawsze wystarczy – czasem trzeba zaktualizować cały runtime/artefakt. - 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.)
- Monitoring i IR
Na dziś opisy źródłowe skupiają się na aktualizacji i ocenie ekspozycji; nie wynika z nich jednoznacznie, iż 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, iż 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 / najważniejsze 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
- OpenSSL Library – Vulnerabilities 3.4 (CVE-2025-15467; wersje podatne i naprawione, opis podatności). (openssl-library.org)
- OpenSSL Library – Vulnerabilities (opis wpływu i scenariuszy CMS/PKCS#7). (openssl-library.org)
- NVD – CVE-2025-15467 (opis techniczny, CWE-787, referencje). (NVD)
- Datadog Security Labs – analiza styczniowego wydania OpenSSL 2026 (kontekst, reachability, wskazówki oceny). (securitylabs.datadoghq.com)
- SecurityWeek – informacja o wydaniu i kontekście (12 podatności, CVE-2025-15467 jako High). (SecurityWeek)
- Ubuntu Security Notice USN-7980-1 (perspektywa dystrybucji / pakietów). (Ubuntu)
