AWS Security Bulletin 2026-005: trzy podatności w AWS-LC (CVE-2026-3336/3337/3338) — obejście walidacji PKCS#7 i boczny kanał timingowy w AES-CCM - Security Bez Tabu

AWS Security Bulletin 2026-005: trzy podatności w AWS-LC (CVE-2026-3336/3337/3338) — obejście walidacji PKCS#7 i boczny kanał timingowy w AES-CCM

Wprowadzenie do problemu / definicja luki

AWS opublikował biuletyn 2026-005-AWS dotyczący biblioteki AWS-LC (Amazon Web Services – Libcrypto) — otwartoźródłowego, ogólnego przeznaczenia komponentu kryptograficznego. Biuletyn opisuje trzy odrębne problemy bezpieczeństwa: dwa dotyczące walidacji obiektów PKCS#7 (funkcja PKCS7_verify()), a trzeci — bocznego kanału czasowego podczas weryfikacji taga w AES-CCM.

W skrócie

  • CVE-2026-3336: obejście weryfikacji łańcucha certyfikatów w PKCS7_verify() przy obiektach PKCS#7 z wieloma podpisującymi (z wyjątkiem ostatniego).
  • CVE-2026-3338: obejście weryfikacji podpisu w PKCS7_verify() przy użyciu Authenticated Attributes.
  • CVE-2026-3337: timing side-channel w dekodowaniu AES-CCM, który może ujawniać poprawność taga uwierzytelniającego.
  • Poprawki są dostępne m.in. w AWS-LC v1.69.0 (oraz odpowiednich wersjach wrapperów/forków FIPS wskazanych przez AWS).

Kontekst / historia / powiązania

AWS-LC jest używany jako fundament kryptografii w różnych projektach i środowiskach (także poprzez bindingi, np. w ekosystemie Rust). W biuletynie AWS wskazuje również identyfikatory GitHub Security Advisories (GHSA) oraz podziękowania dla AISLE Research Team za współpracę w ramach coordinated vulnerability disclosure.

W praktyce istotne jest rozróżnienie:

  • „klienci usług AWS” (konsumenci usług zarządzanych),
  • versus aplikacje używające AWS-LC bezpośrednio (np. własne buildy, kontenery, integracje w C/C++/Rust, komponenty FIPS).

NVD wprost podkreśla, że klienci usług AWS nie muszą podejmować działań, a aktualizacje dotyczą aplikacji korzystających z AWS-LC.

Analiza techniczna / szczegóły luki

CVE-2026-3336 — PKCS7_verify: Certificate Chain Validation Bypass

Problem dotyczy nieprawidłowej walidacji certyfikatów w PKCS7_verify() podczas przetwarzania obiektów PKCS#7 z wieloma signerami: możliwe jest pominięcie weryfikacji łańcucha certyfikatów dla signerów innych niż ostatni.

Zakres wersji (wg AWS):

  • AWS-LC: >= 1.41.0, < 1.69.0
  • aws-lc-sys: >= 0.24.0, < 0.38.0

CVE-2026-3338 — PKCS7_verify: Signature Validation Bypass (Authenticated Attributes)

Drugi błąd w PKCS7_verify() umożliwia obejście weryfikacji podpisu w scenariuszach, gdzie PKCS#7 wykorzystuje Authenticated Attributes.

Zakres wersji (wg AWS):

  • AWS-LC: >= 1.41.0, < 1.69.0
  • aws-lc-sys: >= 0.24.0, < 0.38.0

CVE-2026-3337 — AES-CCM: Timing side-channel w weryfikacji taga

AWS opisuje obserwowalną różnicę czasową (timing discrepancy) w dekodowaniu AES-CCM, która potencjalnie pozwala zdalnie wnioskować o poprawności taga uwierzytelniającego (czyli o tym, czy weryfikacja taga przechodzi).
GitHub advisory doprecyzowuje, że podatność dotyczy implementacji dostępnych przez EVP CIPHER API (m.in. rodziny EVP_aes_*_ccm).

Zakres wersji (wg AWS):

  • AWS-LC: >= 1.21.0, < 1.69.0
  • AWS-LC-FIPS: >= 3.0.0, < 3.2.0
  • aws-lc-sys: >= 0.14.0, < 0.38.0
  • aws-lc-sys-fips: >= 0.13.0, < 0.13.12

Praktyczne konsekwencje / ryzyko

Co to realnie oznacza dla zespołów bezpieczeństwa i deweloperów?

  1. Walidacja podpisanych struktur (PKCS#7 / CMS) może być myląco „zielona”
    Jeśli Twoje systemy przetwarzają podpisane obiekty (np. S/MIME, CMS, podpisane paczki/manifesty, wewnętrzne „signed blobs”), to błędy w PKCS7_verify() mogą prowadzić do akceptacji danych, które powinny zostać odrzucone (w zależności od tego, jak aplikacja buduje logikę zaufania i jak używa API).
  2. Ryzyko wycieku informacji przez czas wykonania (AES-CCM)
    Side-channel nie „łamie” szyfru wprost, ale może umożliwiać rozróżnianie poprawności taga na podstawie czasu odpowiedzi — co w pewnych protokołach i scenariuszach (np. rozproszone usługi, API, urządzenia IoT) bywa użyteczne do wzmacniania ataków adaptacyjnych lub do fingerprintingu.
  3. Różny wpływ na użytkowników usług AWS vs użytkowników biblioteki
    Jeśli korzystasz z usług zarządzanych AWS, komunikat NVD sugeruje brak konieczności działań po stronie klienta. Jeśli jednak kompilujesz/shipujesz AWS-LC (bezpośrednio lub przez bindingi), to aktualizacja jest po Twojej stronie.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu”, w kolejności priorytetu:

  1. Zidentyfikuj użycie AWS-LC w łańcuchu dostaw
    • sprawdź zależności w repo (aws-lc, aws-lc-sys, aws-lc-sys-fips), obrazy kontenerów, artefakty CI, SBOM
    • zweryfikuj, czy gdziekolwiek przetwarzasz PKCS#7/CMS lub używasz AES-CCM
  2. Zaktualizuj do wersji naprawionych (wg AWS)
    • AWS-LC → v1.69.0
    • aws-lc-sys → v0.38.0
    • AWS-LC-FIPS → 3.2.0
    • aws-lc-sys-fips → v0.13.12
  3. Jeśli AES-CCM jest krytyczne i nie możesz od razu zrobić upgrade
    AWS wskazuje ograniczony workaround dla konkretnych parametrów AES-CCM poprzez użycie EVP AEAD API i wybranych implementacji (m.in. warianty „bluetooth” i „matter”), ale podkreśla, że poza tym nie ma znanego obejścia i rekomenduje aktualizację.
  4. Wzmocnij monitoring i testy regresji kryptograficznej
    • dodaj testy jednostkowe/integracyjne, które walidują oczekiwane zachowanie PKCS7_verify() (w tym przypadki multi-signer i authenticated attributes)
    • jeśli masz ścieżki sieciowe wykorzystujące AES-CCM, rozważ testy „constant-time” / analiza czasu odpowiedzi w warunkach labowych

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • PKCS#7/CMS to obszar, w którym błędy często wynikają z subtelnych różnic interpretacji (np. który element jest „zaufanym” signerem, jak budowany jest łańcuch, jak interpretowane są atrybuty). CVE-2026-3336 i CVE-2026-3338 wpisują się w ten wzorzec: problem nie musi dotyczyć „wszystkich podpisów”, tylko konkretnych wariantów struktur i ścieżek walidacji.
  • Timing side-channels w kryptografii zwykle nie są „jednym kliknięciem RCE”, ale są realne tam, gdzie atakujący ma możliwość wykonywania wielu prób i dokładnego pomiaru czasu (albo różnicowania odpowiedzi). CVE-2026-3337 to klasyczny przykład ryzyka, które rośnie w systemach o wysokiej powtarzalności i przewidywalnych ścieżkach wykonania.

Podsumowanie / kluczowe wnioski

  • AWS-LC otrzymało trzy CVE: dwa związane z PKCS7_verify() (obejścia walidacji), jedno związane z timingiem w AES-CCM.
  • Jeśli używasz AWS-LC w aplikacji / bibliotece / kontenerze, zaktualizuj do wersji naprawionych (AWS-LC 1.69.0, odpowiednie wrappery/FIPS).
  • Jeśli jesteś wyłącznie klientem usług zarządzanych AWS, źródła wskazują, że nie powinno być potrzeby działań po Twojej stronie — ale nadal warto zweryfikować, czy nie masz „ukrytego” użycia AWS-LC w komponentach własnych.

Źródła / bibliografia

  1. AWS Security Bulletin 2026-005-AWS — „Issue with AWS-LC…” (Amazon Web Services, Inc.)
  2. NVD: CVE-2026-3336 (wskazania dot. działań i wersji naprawionej) (nvd.nist.gov)
  3. CVE.org: CVE-2026-3337 (cve.org)
  4. CVE.org: CVE-2026-3338 (cve.org)
  5. GitHub Security Advisory (aws-lc-rs): GHSA-65p9-r9h6-22vj (AES-CCM timing) (GitHub)