Archiwa: AI - Strona 175 z 178 - Security Bez Tabu

Tag: AI

Microsoft łata aktywnie wykorzystywaną lukę w jądrze Windows (CVE-2025-62215). Co to znaczy dla Twojej organizacji?

Wprowadzenie do problemu / definicja luki

Podczas listopadowego Patch Tuesday (11 listopada 2025 r.) Microsoft załatał aktywnie wykorzystywaną lukę podniesienia uprawnień w jądrze Windows – CVE-2025-62215. To błąd klasy race condition: atakujący, który ma już możliwość uruchomienia kodu w systemie (np. jako zwykły użytkownik), może „wygrać wyścig” i uzyskać uprawnienia SYSTEM, przejmując pełną kontrolę nad hostem. Microsoft potwierdził obserwacje exploitów w atakach w świecie rzeczywistym (szczegóły kampanii nie zostały ujawnione) i przypisał odkrycie MSTIC/MSRC.

Równocześnie opublikowano łatki do ~63 podatności (według BleepingComputer), w tym czterech oznaczonych przez Microsoft jako „krytyczne” (m.in. GDI+/Graphics Component, Office, Visual Studio, Nuance PowerScribe 360).

W skrócie

  • CVE-2025-62215 (Windows Kernel, EoP) – błąd race condition, pozwala uzyskać SYSTEM po lokalnym wykonaniu kodu; aktywnie wykorzystywany.
  • Zakres aktualizacji – ok. 63 luk (59 „Important”, 4 „Critical” wg ZDI), z czego 29 to EoP i 16 RCE (zestawienie liczbowo różni się nieznacznie między źródłami, zależnie od tego, czy liczone są też aktualizacje Chromium/Mariner).
  • Priorytet – traktować jako pilne; typowy łańcuch: zdalny RCE + lokalny EoP (CVE-2025-62215) = pełne przejęcie hosta.
  • Dodatkowy kontekst – to „lżejszy” miesiąc po październikowej kumulacji (ponad 170 CVE); mimo mniejszej liczby poprawek, ryzyko pozostaje wysokie ze względu na zero-day.

Kontekst / historia / powiązania

Relacje branżowe (SecurityWeek, BleepingComputer, ZDI, Cisco Talos, Qualys) są spójne: mamy jedną potwierdzoną 0-day w kernelu i kilka klas podatności, które często pojawiają się w łańcuchach ataków (Office/GDI+/DirectX/WinSock/CLFS). Talos podaje dla CVE-2025-62215 ocenę CVSS 7.8 i podkreśla „low complexity” przy spełnionych warunkach lokalnego uruchomienia kodu.

Warto odnotować, że Windows 10 przeszedł na ESU (płatne przedłużenie poprawek), co w wielu środowiskach komplikuje zgodność patch-managementu i priorytetyzację.

Analiza techniczna / szczegóły luki

CVE-2025-62215 – Windows Kernel EoP (race condition)

  • Warunek powodzenia: atakujący musi mieć lokalny dostęp i możliwość wykonania kodu (np. po udanym RCE, makrze Office, sideloadingu DLL, LPE przez sterownik, itp.).
  • Mechanizm: współbieżny dostęp do współdzielonego zasobu w jądrze bez właściwej synchronizacji umożliwia modyfikację stanu/struktur i eskalację do NT AUTHORITY\SYSTEM po „wygraniu wyścigu”. Microsoft explicite podkreśla, że exploit wymaga „wygrania race condition”.
  • Łańcuchy ataku w praktyce:
    • Phish → Office RCE (np. CVE-2025-62199/62205/62216) → CVE-2025-62215 (EoP) → trwałość (LsaAddAccountRights, usługi, harmonogram) → C2.
    • Drive-by/plik graficzny → GDI+ RCE (CVE-2025-60724) → kernel EoP.
    • Dev/CI środowiska → VS/Agentic AI RCE (CVE-2025-62214/62222) → kernel EoP.

Inne ważne pozycje (wybór):

  • GDI+ RCE (CVE-2025-60724, CVSS 9.8) – potencjalnie bez interakcji na serwisach parsujących pliki; bardzo groźne w systemach serwerowych skanujących/konwertujących dokumenty.
  • DirectX Graphics Kernel EoP (CVE-2025-60716) – również z elementem race condition (Talos: „high complexity”).
  • CLFS EoP (CVE-2025-60709) – komponent historycznie atrakcyjny dla APT/crimeware (często eksploatowany w poprzednich latach).

Praktyczne konsekwencje / ryzyko

  • Eskalacja po „pierwszym wstrzyknięciu” – 0-day w kernelu zamyka łańcuch ataku, podnosząc uprawnienia z User do SYSTEM; utrudnia triage, bo telemetrycznie wygląda jak „local exploit”, gdy faktyczny wektor był zdalny.
  • Ucieczka z kontenerów/aplikacji „piaskownicy” – w środowiskach z AppContainer/WDAG/ciężkim hardeningiem eskalacja do SYSTEM może obejść izolację.
  • Skutki dla IR/SOC: krótkie okno detekcji; artefakty race condition bywają skąpe; trzeba łączyć alerty z fazy pre-EoP (phish/plik) z nietypowymi zdarzeniami jądra.

Rekomendacje operacyjne / co zrobić teraz

1) Priorytetowe wdrożenie poprawek

  • Windows (wszystkie wspierane edycje): wdrożyć listopadowe cumulative updates. Zgodnie z relacjami branżowymi aktualizacja łata CVE-2025-62215 oraz inne CVE o wysokim ryzyku (GDI+, Office, DirectX).

PowerShell – szybkie sprawdzenie poziomu łatek na hostach

# ostatnie zainstalowane aktualizacje jakościowe
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# sprawdzenie dostępnych aktualizacji (wymaga PSWindowsUpdate)
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -MicrosoftUpdate

# ciche zainstalowanie wszystkich aktualizacji i restart poza godzinami pracy
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot -AutoReboot

Intune – wymuszenie cyklu aktualizacji
Device > Windows > Update rings for Windows 10 and later → Ustaw krótki „Deadline for quality updates” (np. 2 dni) + „Grace period” 0–1 dzień dla krytycznych stacji.

WSUS/SCCM
Zatwierdź „Security Updates” z datą 2025-11-11 dla grup „Pilot” (24–48 h), następnie „Broad” (72–120 h) po smoke-teście zgodności.

2) Weryfikacja wdrożenia

PowerShell – weryfikacja konkretnego KB

# przykładowo sprawdź czy host ma listopadowy CU (KB będzie zależeć od wersji Windows)
$kb="KB5xxxxx"  # wstaw właściwy numer z dokumentacji wydanej dla Twojej wersji
(Get-HotFix -Id $kb -ErrorAction SilentlyContinue) -ne $null

Uwaga: numer KB różni się per wersja (23H2/24H2/25H2/Server). Zweryfikuj dla swojej gałęzi podczas publikacji w MSRC/Release Notes.

3) Wzmocnienie detekcji (MDE/Sysmon/SIEM)

Sysmon – zdarzenia warte korelacji:

  • Event ID 1/5/7/11 (ProcessCreate, ProcessTerminated, ImageLoaded, FileCreate) dla anomalii wokół win32k, ntoskrnl, sterowników grafiki/CLFS;
  • Nietypowe wątki w procesach niskoprzywilejowych prowadzące do zmian usług/kluczy LSA.

Microsoft Defender for Endpoint – zapytania KQL (Advanced Hunting):

// Podejrzane podniesienia uprawnień po niedawnym otwarciu dokumentu
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where FileName in~ ("cmd.exe","powershell.exe","rundll32.exe","reg.exe")
) on DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
// Szybka detekcja tworzenia usług po EoP
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
| where InitiatingProcessAccountName !in~ ("SYSTEM","LOCAL SERVICE","NETWORK SERVICE")

4) Twarde ograniczenie wektorów wstępnych (do czasu pełnego patchowania)

  • Blokada podglądu w Office / Ochrona przed makrami – błąd Office RCE (CVE-2025-62199/62205/62216) może być łączony z EoP; ogranicz Preview Pane i makra z internetu.
  • Filtrowanie plików graficznych/metafili (GDI+ RCE, CVE-2025-60724) w bramkach, DLP, serwerach konwersji.
  • WDAC / AppLocker – polityki ograniczające uruchamianie binariów spoza zaufanych ścieżek.
  • EDR: monitoruj nietypowe TokenElevationType, SeDebugPrivilege, tworzenie usług, modyfikacje LSA/TTY.

5) Zarządzanie ryzykiem w Windows 10 (ESU)

Jeśli utrzymujesz Windows 10, zaplanuj ESU lub migrację do Windows 11; listopadowe łatki są pierwszym cyklem ESU i brak ich wdrożenia otwiera lukę na hostach „legacy”.

Różnice / porównania z innymi przypadkami

  • Wzorzec „RCE + EoP” jest typowy: w ostatnich latach wiele kampanii łączyło dokument/preview-based RCE (Office/GDI+) z kernel EoP (CLFS/win32k/DirectX). Bieżący zestaw CVE dokładnie wpisuje się w ten schemat.
  • Dynamika Patch Tuesday: po „ciężkim” październiku (ZDI raportował ~177 CVE) listopad wygląda spokojniej liczbowo, ale jakościowo mamy 0-day w kernelu – więc priorytet pozostaje wysoki.

Podsumowanie / kluczowe wnioski

  • CVE-2025-62215 to realne, potwierdzone zagrożenie: aktywny exploit + eskalacja do SYSTEM. Potraktuj jako priorytet P0.
  • Zastosuj listopadowe aktualizacje na Windows/Office/VS/DirectX/GDI+ jak najszybciej, ze szczególnym naciskiem na stacje użytkowników i serwery parsujące dokumenty.
  • W SOC skup się na korelacji: źródłowe zdarzenie (phish/plik) → nietypowe procesy → trwałość po EoP.
  • Jeśli masz Windows 10, upewnij się, że włączone są kanały ESU albo przyspiesz migrację.

Źródła / bibliografia

  1. SecurityWeek – „Microsoft Patches Actively Exploited Windows Kernel Zero-Day” (11.11.2025). Potwierdzenie 0-day (CVE-2025-62215), klasa błędu (race condition), zakres miesiąca. (SecurityWeek)
  2. BleepingComputer – „Microsoft November 2025 Patch Tuesday fixes 1 zero-day, 63 flaws” – liczby, lista kategorii, przypisanie MSTIC/MSRC. (BleepingComputer)
  3. Zero Day Initiative – „The November 2025 Security Update Review” – komentarz techniczny, kontekst (liczby, porównanie do października), akcent na łańcuch RCE→EoP. (Zero Day Initiative)
  4. Cisco Talos – „Microsoft Patch Tuesday for November 2025 — Snort rules and prominent vulnerabilities” – CVSS, krytyczne wpisy (GDI+/Office/VS/DirectX), zasady Snort. (Cisco Talos Blog)
  5. Qualys – „Microsoft Patch Tuesday, November 2025 Security Update Review” – podsumowanie kategorii, opisy GDI+/Office/DirectX, potwierdzenie charakteru CVE-2025-62215. (Qualys)

Popularna biblioteka JavaScript expr-eval z krytyczną luką RCE (CVE-2025-12735)

Wprowadzenie do problemu / definicja luki

W bibliotece expr-eval (popularny parser i ewaluator wyrażeń matematycznych w JavaScript) ujawniono krytyczną podatność pozwalającą na zdalne wykonanie kodu (RCE) po przekazaniu złośliwego obiektu „kontekstu” do funkcji evaluate(). Problem został oznaczony jako CVE-2025-12735, a według oceny CISA (CVSS 3.1) ma wagę 9.8 – CRITICAL. Luka dotyczy zarówno oryginalnego pakietu expr-eval, jak i aktywnie utrzymywanego forka expr-eval-fork (naprawa dostępna od wersji 3.0.0).

W skrócie

  • Co: RCE poprzez złośliwe funkcje w obiekcie kontekstu przekazywanym do Parser.evaluate().
  • Zakres: expr-eval (oryginalny projekt) i expr-eval-fork (fork).
  • Nasilenie: CVSS 9.8 (CISA ADP).
  • Status poprawek: stabilna poprawka w expr-eval-fork v3.0.0; dla oryginalnego repo istnieje PR z łatą (#288), ale brak nowego wydania. Rekomendowana migracja do forka 3.0.0+.

Kontekst / historia / powiązania

expr-eval jest powszechnie używany w kalkulatorach webowych, narzędziach edukacyjnych, finansowych oraz – coraz częściej – w systemach NLP/AI, które parsują fragmenty matematyczne z tekstu. Oryginalne repozytorium jest rozwijane nieregularnie; społeczność utrzymuje forka expr-eval-fork, który wcześniej rozwiązywał inne kwestie bezpieczeństwa i utrzymania. CERT-CC i NVD odnotowują, że biblioteka ma setki zależności pośrednich, co zwiększa zasięg oddziaływania podatności.

Analiza techniczna / szczegóły luki

Przyczyna: Funkcja evaluate() przyjmuje obiekt context (zbiór zmiennych i funkcji dostępnych w wyrażeniu). Brak prawidłowej walidacji/ograniczeń umożliwia przekazanie obiektów-funkcji, które parser następnie wywołuje w trakcie ewaluacji. To otwiera drogę do wykonywania niepożądanego kodu – w środowisku Node.js nawet do wywołań systemowych. NVD klasyfikuje problem jako skutkujący przejęciem poufności, integralności i dostępności (C:H/I:H/A:H).

Stan poprawek:

  • expr-eval-fork: wydanie 3.0.0 zawiera allowlist bezpiecznych funkcji, mechanizm rejestracji funkcji użytkownika i testy wymuszające ograniczenia.
  • expr-eval (oryginalne): istnieje Pull Request #288 od CERT-CC z analogiczną łatą; brak potwierdzanej publikacji nowej wersji w npm.

Identyfikatory i doradztwa: CVE-2025-12735, GHSA-jc85-fpwf-qm7x (GitHub Advisory).

Minimalny przykład zagrożonego wzorca (edukacyjnie, bez payloadu)

import { Parser } from 'expr-eval';

// Niebezpieczne: bezkrytyczne przekazywanie "context" z funkcjami od użytkownika
const parser = new Parser();
const expr = parser.parse('customFn(x) + y');

// "context" pochodzi np. z wejścia użytkownika (to błąd!)
const unsafeContext = {
  x: 2,
  y: 3,
  // użytkownik może wstrzyknąć dowolną funkcję
  customFn: (n) => n * 10,
};

console.log(expr.evaluate(unsafeContext));

Wniosek: Sam fakt, że funkcje z kontekstu są wywoływane, stanowi wektor wykonania kodu. W Node.js zamiast nieszkodliwego n * 10 atakujący może próbować odwołań do zasobów środowiska. Naprawa polega na odrzuceniu funkcji z kontekstu, whitelisting i jawnej rejestracji dopuszczalnych funkcji.

Praktyczne konsekwencje / ryzyko

  • Aplikacje serwerowe (Node.js): ryzyko RCE i dostępu do zasobów hosta, w tym plików, poświadczeń czy usług sieciowych. CVSS 9.8 od CISA odzwierciedla pełen kompromis (C/I/A = H).
  • Front-end (przeglądarka): brak bezpośredniego dostępu do systemu, ale możliwość nadużyć (kradzież tokenów, interakcje z API w kontekście użytkownika).
  • Łańcuch dostaw: biblioteka jest zależnością pośrednią w wielu projektach — podatność może „dotrzeć” do Was nawet, jeśli nie importujecie jej wprost.

Rekomendacje operacyjne / co zrobić teraz

1) Szybka weryfikacja zależności

  • SBOM/grep: # npm npm ls expr-eval expr-eval-fork || true # pnpm pnpm ls expr-eval expr-eval-fork || true # yarn yarn why expr-eval || true
  • Skan doradztw: sprawdź GHSA i CVE w pipeline (np. npm audit, GitHub Dependabot).

2) Aktualizacja i pinning

  • Preferowany wariant: natychmiast **migruj do expr-eval-fork ≥ 3.0.0. npm i expr-eval-fork@^3.0.0 # lub w package.json ustaw: # "overrides": { "expr-eval": "npm:expr-eval-fork@^3.0.0" } Jeśli używacie pakietu, który pośrednio ciągnie expr-eval, rozważcie overrides/resolutions albo zgłoście issue do maintenera.
  • Oryginalny expr-eval: dopóki nie ma wydania z łatą, nie polegajcie na tym pakiecie w kontekście niezaufanego wejścia. PR #288 istnieje, ale brak gwarancji release’u.

3) Dodatkowe twarde zabezpieczenia (defense-in-depth)

  • Blokada funkcji w kontekście: nie przekazuj żadnych funkcji z danych użytkownika; jeśli musisz, stosuj allowlistę i własną fabrykę funkcji.
  • Sandboxing: w Node.js rozważ izolację ewaluacji (np. oddzielny proces/VM, worker_threads, ograniczone uprawnienia).
  • WAF / filtrowanie: ogranicz długość, znaki i słowa kluczowe w wyrażeniach, jeżeli użytkownicy dostarczają stringi do ewaluacji.
  • Logowanie i detekcja anomalii: monitoruj nietypowe wyrażenia i błędy parsera.

4) Testy regresyjne – przykład „bezpiecznego” wzorca po aktualizacji

import { Parser } from 'expr-eval-fork';

// jawna rejestracja dopuszczalnych funkcji
const allowed = {
  abs: Math.abs,
  ceil: Math.ceil,
  floor: Math.floor,
  // ...lista minimalna, bez funkcji dostępowych
};

const parser = new Parser({ functions: allowed });

// Do wyrażenia przekazujemy wyłącznie PRYMITYWY (liczby/napisy/boole)
// i ewentualnie nazwy dopuszczonych funkcji; brak dowolnych obiektów-funkcji
const expr = parser.parse('abs(x) + ceil(y)');
const safeContext = { x: -3.14, y: 2.2 };

console.log(expr.evaluate(safeContext)); // 6

5) Działania w CI/CD

  • Wymuś fail build przy wykryciu expr-eval < bezpiecznych wersji (policy as code).
  • Dodaj overrides/resolutions w monorepo i lockfile maintenance.
  • Publikuj nową wersję swoich bibliotek, aby konsumenci dostali zależność z poprawką (tzw. republish chain).

Różnice / porównania z innymi przypadkami

  • Analogiczne klasy błędów: CWE-94 („Improper Control of Code Generation”) – sytuacje, gdy system pozwala na wstrzyknięcie kodu poprzez „rozszerzalne” mechanizmy (np. eval-like, dynamiczne funkcje, konteksty). W expr-eval problem był subtelny, bo dotyczył wywoływania funkcji z kontekstu, a nie tylko parsowania tekstu. (Por. wpisy doradcze GHSA/NVD.)
  • Różnica do klasycznych XSS/RCE: tu łańcuch dostaw oraz biblioteka „bezpieczna zamiast eval” paradoksalnie stała się wektorem RCE przy niewłaściwej walidacji/konfiguracji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-12735 to krytyczna luka w expr-eval umożliwiająca RCE przez złośliwe funkcje w kontekście evaluate().
  • Najbezpieczniejsza ścieżka: migracja do expr-eval-fork 3.0.0+, pinning i republish bibliotek zależnych.
  • Nawet po aktualizacji stosuj zasadę najmniejszego zaufania wobec wejścia użytkownika i allowlistę funkcji.
  • Zweryfikuj łańcuch zależności – podatność często wchodzi pośrednio.

Źródła / bibliografia

  • BleepingComputer: pierwsze doniesienia, status patchy i rekomendacja migracji do expr-eval-fork 3.0.0. (BleepingComputer)
  • NVD (CVE-2025-12735) – opis, metryki, referencje, CVSS 9.8 wg CISA-ADP. (NVD)
  • CERT-CC Vulnerability Note VU#263614 – opis techniczny, wpływ na projekty AI/NLP, zalecenia. (kb.cert.org)
  • GitHub PR #288 (silentmatt/expr-eval) – propozycja łaty od CERT-CC, status w oryginalnym repo. (GitHub)
  • GitHub Advisory (GHSA-jc85-fpwf-qm7x) – doradztwo bezpieczeństwa. (GitHub)

LPI Security Essentials (Moduł 022.4) -Szyfrowanie Danych

Zanim zaczniesz

Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.

Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.

Czytaj dalej „LPI Security Essentials (Moduł 022.4) -Szyfrowanie Danych”

Microsoft ujawnia „Whisper Leak”: atak boczny ujawniający temat rozmów z LLM mimo szyfrowania

Wprowadzenie do problemu / definicja luki

Microsoft opisał nowy atak boczny na zdalne modele językowe (LLM), nazwany Whisper Leak. Pozwala on pasywnemu podsłuchującemu — np. operatorowi sieci, atakującemu w tej samej sieci Wi-Fi lub obserwatorowi na łączu — wnioskować o temacie rozmowy z chatbotem, mimo że ruch jest szyfrowany (HTTPS/TLS). Skuteczność ataku wynika z analizy metadanych ruchu: rozmiarów i czasów nadejścia pakietów podczas strumieniowania odpowiedzi modelu. To nie jest błąd kryptograficzny TLS, tylko nadużycie informacji ujawnianej przez samą naturę strumieniowania tokenów.

W skrócie

  • Co wycieka? Nie treść wiadomości, lecz klasa/temat rozmowy (np. pytania o pranie pieniędzy, zdrowie, politykę).
  • Jak? Klasyfikator uczy się wzorców z sekwencji rozmiarów pakietów i odstępów czasowych przy strumieniowaniu odpowiedzi.
  • Skuteczność: Microsoft raportuje dla wielu popularnych modeli wyniki >98% AUPRC; w scenariuszu 1 rozmowa na 10 000 „szumu” możliwa jest 100% precyzja przy 5–50% pokrycia przypadków docelowych.
  • Kto załatał? Po jawnej koordynacji dostawcy tacy jak OpenAI, Mistral, Microsoft, xAI wdrożyli pierwsze obfuscatory strumienia (dodawanie losowego tekstu / parametry API) i inne utrudnienia.
  • Ryzyko: Realne dla użytkowników w środowiskach podwyższonego nadzoru (ISP, sieci publiczne), organizacji korzystających z LLM w wrażliwych domenach (prawo, zdrowie, compliance).

Kontekst / historia / powiązania

Whisper Leak wpisuje się w rosnące portfolio ataków kanałami pobocznymi na LLM:

  • Token-length side-channel (USENIX ‘24) — na podstawie długości tokenów (wnioskowanej z rozmiarów pakietów) rekonstruowano częściowo odpowiedzi oraz temat rozmowy.
  • Remote timing attacks (2024) — wykorzystują zależności czasowe w efektywnym wnioskowaniu (np. speculative decoding) do rozpoznawania właściwości promptu/odpowiedzi.

Microsoft buduje na tych pracach, łącząc rozmiary i timingi pakietów w jeden wektor cech i pokazując, że to wystarcza do trafnego klasyfikowania tematów w ruchu szyfrowanym.

Analiza techniczna / szczegóły luki

Założenie ataku: napastnik passive network observer ma podgląd do ruchu TLS między klientem a usługą LLM, ale go nie deszyfruje.

Powierzchnia ataku: większość klientów LLM strumieniuje odpowiedź — tokeny (lub małe grupy tokenów) są wysyłane na bieżąco. Dla TLS oznacza to ciąg pakietów o pewnych rozmiarach i przerwach. Ponieważ rozmiar szyfrogramu ~ rozmiarowi plaintextu + stałe narzuty, wzorce długości i czasu stają się „odciskiem palca” danego tematu i sposobu generacji.

Pipeline Whisper Leak (upraszczając):

  1. Zbieranie próbek: generowanie zestawu wariantów pytań z wrażliwego tematu (POC: „legalność prania pieniędzy”) oraz dużego zbioru losowych pytań-szumu; rejestrowanie ruchu (np. tcpdump) dla różnych dostawców/modeli.
  2. Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
  3. Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
  4. Ewaluacja: metryka AUPRC na zbiorze ekstremalnie niezrównoważonym (np. 1:10 000 target:noise). Wynik: >98% dla wielu usług; w praktycznym modelu nadzoru wysoka precyzja przy istotnym recall.

Dlaczego to działa?

  • Autoregresja i (niekiedy) optymalizacje efektywności wprowadzają zależne od danych różnice czasowe.
  • TLS nie ukrywa rozmiarów i timingów rekordów/aplikacyjnych ramek; to metadane.

Minimalny PoC zbierania cech (edukacyjnie):

# przechwyć sesję HTTPS do dostawcy LLM (np. domena api.*)
sudo tcpdump -i eth0 -w llm.pcap 'tcp port 443 and host api.example-llm.com'

# wyodrębnij rozmiary i interwały z PCAP (pyshark)
import pyshark, numpy as np
cap = pyshark.FileCapture('llm.pcap', display_filter='tcp && tls')
sessions = {}
for p in cap:
    key = (p.ip.src, p.tcp.stream) if 'TLS' in p else None
    if not key: continue
    ts = float(p.sniff_timestamp)
    size = int(p.length)  # długość ramki
    sessions.setdefault(key, []).append((ts, size))
features = []
for k, seq in sessions.items():
    seq.sort()
    dts = np.diff([t for t,_ in seq], prepend=seq[0][0])
    feats = list(zip([s for _,s in seq], dts))
    features.append(feats)
print("sesji:", len(features))

(Powyższe służy naukowym ćwiczeniom nad detekcją wewnętrzną — nie do nadużycia).

Praktyczne konsekwencje / ryzyko

  • Model zagrożeń: ISP, operator chmury pośredniczącej, współużytkownicy Wi-Fi, każdy z możliwością passive sniffing.
  • Co można wywnioskować? Temat konwersacji (np. przestępczość finansowa, medyczne zapytania, poglądy polityczne). To wystarczy do profilowania i wyzwolenia działań (cenzura, targetowanie).
  • Sektory wrażliwe: prawo, zdrowie, finanse, sektor publiczny, media/NGO w krajach restrykcyjnych.
  • Skala: badanie obejmowało 28 modeli głównych dostawców; część z nich osiągała wyniki umożliwiające nadzór na masową skalę.

Rekomendacje operacyjne / co zrobić teraz

Dla dostawców/usług LLM (serwer)

  1. Obfuskacja strumienia odpowiedzi — dodawanie losowego tekstu o zmiennej długości do chunków strumieniowych (wprowadzono m.in. w OpenAI, Azure; Mistral dodał dedykowany parametr). Silnie obniża skuteczność ataku.
  2. Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
  3. Packet injection / cover traffic — wtryski dodatkowych ramek/”szumu” (koszt: 2–3× narzut pasma).
  4. Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
  5. Ciągła ewaluacja — testy regresyjne pod kątem wycieków metadanych (AUPRC/ROC na syntetycznych zbiorach tematów).

Dla integratorów/architektów (klient, brzeg)

  • Wyłącz strumieniowanie dla przepływów „tajemniczych” (domyślnie stream=False / brak streamu w większości SDK). Segmentuj ruch (oddzielny endpoint/trasowanie dla zapytań wrażliwych).
  • Preferuj dostawców z wdrożonymi mitigacjami (OpenAI, Azure, Mistral, xAI — wg stanu na 7–9 listopada 2025).
  • VPN/zero-trust egress na wyjściu organizacji (utrudnia lokalnym przeciwnikom korelację strumienia, choć nie eliminuje ataku u dostawcy/ISP).
  • Buduj detektory anomalii na własnych bramach (np. wykrywanie nietypowych wzorców TLS/HTTP2 dla usług LLM, by lokalnie oceniać ryzyko ekspozycji).

Dla zespołów bezpieczeństwa (SOC/Blue)

  • Policy awareness: oznacz tematy wrażliwe i wymuś polityki non-streaming + dostawcy z mitigacjami.
  • Monitoring: rejestrowanie metryk egress (rozmiary rekordów, jitter) w kanałach do usług LLM, by audytować zgodność.
  • Szkolenia użytkowników: nie zadawać pytań o wysokiej wrażliwości przez LLM w sieciach niezaufanych (hotele, kawiarnie).

Przykładowe „kontrole” w praktyce (demo):

  • Blokowanie strumieniowania po stronie reverese-proxy (np. endpoint „sensitive” przekierowany do niestreamingowej ścieżki API).
  • Kontrola jakości dostawcy — test A/B: wysyłaj paczkę 100 pytań „sensitive” i 10 000 pytań „noise”; mierz AUPRC własnym klasyfikatorem metadanych — jeśli > próg (np. 0.9), eskaluj do zmiany dostawcy/konfiguracji.

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

  • Whisper Leak vs. Token-length (Weiss et al. 2024): Weiss celował w rekonstrukcję treści bazując na długościach tokenów; Whisper Leak skupia się na klasyfikacji tematu na bazie rozmiarów i timingów pakietów — skuteczne nawet, gdy usługodawca grupuje tokeny.
  • Whisper Leak vs. Remote Timing (Carlini & Nasr 2024): Carlini/Nasr eksploitują optymalizacje efektywności (np. speculative decoding) i subtelne różnice czasowe; Whisper Leak korzysta z makro-wzorca strumienia (rozmiar+czas) i działa na popularnych usługach.

Podsumowanie / kluczowe wnioski

  • Metadane ruchu LLM potrafią zdradzić temat rozmowy mimo TLS.
  • Atak jest praktyczny przy masowym nadzorze (ISP/Wi-Fi), co rodzi realne ryzyka dla prywatności i compliance.
  • Mitigacje istnieją, ale to trade-off koszt/latencja/jakość i nie dają pełnej eliminacji — potrzebny defense-in-depth po stronie dostawcy i rozsądna higiena użytkowania po stronie klienta.

Źródła / bibliografia

  1. Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
  2. McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
  3. Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
  4. Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
  5. The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)

GlassWorm znowu na OpenVSX: trzy nowe rozszerzenia VS Code z ukrytym malware

Wprowadzenie do problemu / definicja luki

Na OpenVSX (alternatywny rejestr rozszerzeń VS Code) wykryto powrót kampanii GlassWorm – zestawu złośliwych rozszerzeń wykorzystujących niewidzialne znaki Unicode do ukrywania i wykonywania JavaScriptu. Nowa fala obejmuje 3 rozszerzenia (m.in. ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs) i według bieżących raportów odnotowała łącznie >10 tys. pobrań. Kampania kontynuuje wcześniej opisane techniki: C2 w łańcuchu Solana, kradzież tokenów GitHub/npm/OpenVSX oraz danych portfeli krypto z 49 popularnych wtyczek.

W skrócie

  • Co się stało: po październikowych czyszczeniach OpenVSX znów pojawiły się 3 zainfekowane rozszerzenia z ukrytym ładunkiem GlassWorm.
  • Jak działa: payload jest schowany w znakach PUA/VS (Private Use Area/Variation Selectors) – „puste” w edytorze, ale dekodowane i wykonywane przez JS. C2 i aktualizacje są osadzane w transakcjach Solana (trwałość, anonimizacja, niskie koszty).
  • Po co: kradzież sekretów (GitHub, npm, OpenVSX), drenaż krypto, tworzenie SOCKS proxy/HVNC i budowa infrastruktury przestępczej na stacjach devów.
  • Skala i spór: OpenVSX informował, że incydent z października był „opanowany” i że nie była to autonomiczna samoreplikacja; jednak badacze widzą „samopowielanie” przez kradzież i użycie poświadczeń.
  • Nowość: potwierdzone wejście na GitHub (commity z doklejonym, ukrytym dekoderem + eval) – to rozszerza wektor poza marketplace.

Kontekst / historia / powiązania

Pierwsza fala GlassWorm została opisana 20 października 2025 r., gdy wykryto pakiet zainfekowanych rozszerzeń na OpenVSX i w marketplace Microsoftu (łączny licznik pobrań szacowany na ok. 35,8 tys., choć mógł być sztucznie zawyżony przez atakujących). 2 listopada OpenVSX ogłosił rotację tokenów i dodatkowe zabezpieczenia po wykryciu wycieku >550 sekretów; jednocześnie podkreślił, że kod nie był „samoreplikującym się” robakiem w klasycznym sensie. 6 listopada badacze Koi i Aikido pokazali jednak nową falę oraz pivot na GitHub. 8 listopada media potwierdziły trzy świeże rozszerzenia na OpenVSX.

Analiza techniczna / szczegóły luki

1) „Niewidzialny” ładunek

  • Atak wykorzystuje PUA/VS (np. zakresy U+E000–U+F8FF, U+FE00–U+FE0F), które nie renderują się w edytorze, ale są parsowane przez dekoder w JS. Typowy wzorzec: dekoder mapujący punkty kodowe → bajty → eval. Na GitHub widziano jednolinijkowy wariant, który dołączał dekoder na końcu pliku.

2) Kanał C2/aktualizacji w Solanie

  • Rozszerzenia pobierają następne etapy na podstawie transakcji Solana (w polach danych trzymane są base64 z URL-ami serwerów C2). Rozwiązanie trudne do zdejmowania (odporne, tanie, anonimowe). Backup: Google Calendar z linkiem base64 w tytule wydarzenia.

3) Zdolności końcowe

  • Kradzież tokenów/logowań (GitHub/npm/OpenVSX), portfeli krypto (49 wtyczek), uruchamianie SOCKS proxy, HVNC (ukryty VNC) – praktycznie przejęcie stacji deweloperskiej jako węzła przestępczego.

4) Infrastruktura i IOC

  • Koi w nowej fali wskazało, że używana jest ta sama infrastruktura (zaktualizowane wskaźniki C2 publikowane w Solanie; przykładowo w raporcie widnieją adresy 199.247.10.166 oraz 199.247.13.106:80/wall jako punkty komunikacji/eksfiltracji).

Praktyczne konsekwencje / ryzyko

  • Łańcuchowe kompromitacje: kradzione tokeny wydawnicze pozwalają wstrzykiwać złośliwe aktualizacje do innych rozszerzeń/repozytoriów/teamów.
  • Trwałość i trudne wyłączenie: C2 na blockchainie zmniejsza skuteczność klasycznych Takedownów. Zmiana transakcji → nowy endpoint → „samoleczenie” C2.
  • Ryzyko finansowe i reputacyjne: wyciek sekretów organizacji, kradzież krypto, nadużycie zasobów (proxy, botnet z dev-workstation).
  • Rozszerzenie wektora: pojawienie się ukrytych commitów na GitHub (AI-like, wiarygodne modyfikacje) utrudnia code review i detekcję.

Rekomendacje operacyjne / co zrobić teraz

0) Szybkie kroki IR (dla SOC/ITSec)

  1. Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
    • ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs.
  2. Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
  3. Rotuj sekrety: patche PAT/ghp, npm tokens, OpenVSX tokens, klucze do CI/CD; wymuś 2FA i SSO. (OpenVSX przeszedł już rotację tokenów, ale Twoja organizacja musi zrobić to samo).

1) Wykrywanie „niewidzialnego” kodu (proste skrypty)

Linux/macOS – skan katalogów rozszerzeń VS Code/VSCodium

# VS Code i VSCodium: typowe ścieżki
EXT_DIRS=("$HOME/.vscode/extensions" "$HOME/.vscode-oss/extensions" "$HOME/.vscode-insiders/extensions")
# Znaki PUA/VS: U+E000–U+F8FF, U+FE00–U+FE0F, U+E0100–U+E01EF
for d in "${EXT_DIRS[@]}"; do
  [ -d "$d" ] || continue
  echo "[*] Skanuję $d"
  grep -RIl --include='*.js' --include='*.ts' \
    -P "[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]" "$d" || true
done

Windows (PowerShell)

$paths = @("$env:USERPROFILE\.vscode\extensions", "$env:USERPROFILE\.vscode-oss\extensions")
$pattern = '[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]'
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem -Recurse -Include *.js,*.ts -Path $p |
      Select-String -Pattern $pattern -AllMatches | Select-Object Path,LineNumber
  }
}

Prosty YARA snippet (heurystyka):

rule Invisible_Unicode_PUA_Eval_JS {
  meta: author="BlueTeam" description="GlassWorm-like hidden code"
  strings:
    $pua = /[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]+/u
    $eval = /eval\s*\(/ nocase
  condition:
    uint16(0) == 0xFFFE or uint16(0) == 0xFEFF or filesize < 5MB and $pua and $eval
}

2) Usuwanie podejrzanych rozszerzeń

# VS Code
code --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
code --uninstall-extension ai-driven-dev.ai-driven-dev
code --uninstall-extension adhamu.history-in-sublime-merge
code --uninstall-extension yasuyuky.transient-emacs

# VSCodium
codium --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
codium --uninstall-extension ai-driven-dev.ai-driven-dev
...

3) Twardnienie łańcucha wydawniczego

  • Sekrety: ogranicz TTL tokenów, wprowadź krótko żyjące PAT, automatyczną re-rotację po wykryciu wycieku; secret scanning w CI. (Zgodne z kierunkiem zmian deklarowanych przez OpenVSX).
  • Publikacja rozszerzeń: SBOM + skan artefaktów przed publikacją, signowanie, zasada 4-oczu na „release”.
  • Review kodu: wymuś widoczność znaków niewidzialnych w IDE i Diffach (np. włącz „Render Control Characters” w VS Code, używaj pre-commit hooków skanujących PUA). (W raporcie Aikido wskazano, że interfejsy nie zawsze oznaczały te znaki).
  • Egress i DNS: blokady do znanych IOC oraz monitorowanie zapytań powiązanych z Solaną używaną jako kanał C2 (telemetria proxy, NetFlow/Zeek).

Różnice / porównania z innymi przypadkami

  • Klasyczne „tylne drzwi” w npm (post-install, skrypty lifecycle) były wyraźniejsze w kodzie; tutaj ładunek „nie istnieje gołym okiem” i potrafi przenikać code review.
  • C2 w Solanie to nowszy trend utrudniający Takedown – w porównaniu do typowych domen/URL na VPS, które łatwiej zawiesić.
  • Spór o „worma”: OpenVSX wskazuje, że brak autonomicznej replikacji; badacze argumentują, że automatyczne aktualizacje + wykorzystanie wykradzionych tokenów de facto umożliwia rozprzestrzenianie się w ekosystemie. Wniosek operacyjny: dla obrony nie ma to znaczenia – ścieżka propagacji i tak omija kontrole.

Podsumowanie / kluczowe wnioski

  • Niewidzialny kod + blockchain C2 + kradzież sekretów = bardzo skuteczny model ataku na ekosystemy developerskie.
  • Nowa fala na OpenVSX pokazuje, że nawet po rotacji tokenów atakujący szybko wracają – potrzebne są krótkie TTL, skanowanie podczas publikacji i silne procesy w organizacjach.
  • Blue Teamy powinny wdrożyć skan PUA, bloki IOC, telemetrię egress i procedury IR wyspecjalizowane dla stacji developerskich (zależne od IDE/marketplace).

Źródła / bibliografia

  1. BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
  2. BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
  3. Eclipse Foundation (OpenVSX) – aktualizacja bezpieczeństwa, rotacje tokenów i stanowisko nt. „self-replicating” (27.10.2025; podsumowane także 02.11.2025). (Eclipse Foundation Staff Blogs)
  4. Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
  5. Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)

Ollama i NVIDIA: nowe luki uderzają w infrastrukturę AI. Co musi zrobić dział SecOps?

Wprowadzenie do problemu / definicja luki

Badacze ujawnili świeży zestaw podatności w popularnych elementach infrastruktury AI: w silniku modeli Ollama oraz w stosie NVIDIA (Triton Inference Server i Container Toolkit/GPU Operator). Część błędów umożliwia zdalne wykonanie kodu (RCE) bez uwierzytelnienia lub ucieczkę z kontenera do hosta, co wprost zagraża klastrom Kubernetes i serwerom GPU. Informacje o nowych lukach i ich naprawach potwierdza m.in. serwis Dark Reading oraz biuletyny producentów.

W skrócie

  • Produkty narażone (przykłady):
    • Ollama – m.in. nowsze zgłoszenia: CVE-2025-51471 (token-steal/bypass auth), wcześniejsze: CVE-2024-37032 (RCE „Probllama”), CVE-2024-28224 (DNS rebinding), plus błędy DoS/overflow.
    • NVIDIA – Container Toolkit/GPU Operator: CVE-2025-23266 (krytyczny container escape, CVSS 9.0) i CVE-2025-23267 (link-following/DoS).
  • Wpływ: przejęcie serwera inferencji, kradzież modeli i danych, eskalacja uprawnień z kontenera do hosta, dostęp do innych workloadów na tym samym węźle GPU.
  • Naprawy:
    • NVIDIA Container Toolkit ≥ 1.17.8 (oraz odpowiednie wersje GPU Operator/Device Plugin/MIG Manager).
    • Ollama – aktualizacja do wydań z łatami (m.in. po CVE-2024-37032 oraz po CVE-2025-51471).

Kontekst / historia / powiązania

Od 2024 r. infrastruktura AI trafia coraz częściej na celownik: Wiz Research opisał RCE w Ollama (CVE-2024-37032, „Probllama”) – łatwe do sprowokowania przez błędy walidacji i brak natywnego uwierzytelniania, zwłaszcza w domyślnie publicznych wdrożeniach Docker. NCC Group wcześniej udowodniło, że DNS rebinding pozwala atakować lokalne instancje Ollama przez przeglądarkę ofiary. Równolegle 2025 przyniósł NVIDIAScape – krytyczny escape w Container Toolkit. Trend potwierdzają media branżowe: środek ciężkości badań przesuwa się z prompt-injection do warstwy infrastruktury (serwery inferencji, rejestry modeli, kontenery GPU).

Analiza techniczna / szczegóły luki

Ollama

  1. CVE-2024-37032 („Probllama”) – RCE
    • Wada w obsłudze manifestów przy /api/pull pozwalała na path traversal i arbitrary file write/read, co w deploymentach Docker (root, 0.0.0.0) dawało prostą ścieżkę do RCE (np. przez manipulację ld.so.preload). Zalecana aktualizacja do wersji z 08.05.2024+.
  2. CVE-2024-28224 – DNS rebinding
    • Atak z poziomu przeglądarki ofiary omijał Same-Origin Policy, umożliwiając zdalny dostęp do API Ollama na localhost, eksfiltrację plików oraz operacje na modelach. Naprawione w v0.1.29; rekomendowane m.in. sprawdzanie nagłówka Host i TLS, także dla loopback.
  3. CVE-2025-51471 – kradzież tokenów / obejście auth
    • Cross-Domain Token Exposure: złośliwy WWW-Authenticate realm z /api/pull mógł wykradać tokeny i obchodzić kontrolę dostępu. Dotyczyło Ollama 0.6.7; patrz NVD/GitHub Advisory i poprawki projektu.

Wniosek: w praktyce te trzy klasy błędów łączą się w łańcuch ataku: rebinding ⇒ token-steal ⇒ pull/push z prywatnego rejestru ⇒ RCE/eksfiltracja.

NVIDIA Container Toolkit / GPU Operator

  • CVE-2025-23266 (CVSS 9.0) – błąd w hookach inicjalizacji kontenera; w pewnych konfiguracjach umożliwiał ucieczkę z kontenera i wykonanie kodu z podwyższonymi uprawnieniami na hoście.
  • CVE-2025-23267 (CVSS 8.5) – podatność w hooku update-ldcache; specjalnie spreparowany obraz mógł prowadzić do link following, skutkując manipulacją danymi/DoS.
  • Wersje naprawcze: Toolkit 1.17.8, GPU Operator 25.3.2, Device Plugin 0.17.3, MIG Manager 0.12.2; dodatkowe uwagi dla RHEL/OpenShift i notatka, że konfiguracje z crun nie są dotknięte 23266.

Praktyczne konsekwencje / ryzyko

  • Kradzież modeli i promptów, modyfikacja wag i artefaktów (supply-chain modeli), sabotaż inferencji.
  • Pivot z kontenera do hosta GPU (23266) ⇒ dostęp do innych namespace’ów/kontenerów na węźle, wyciek danych klientów i eskalacja w klastrze.
  • Ataki z przeglądarki na lokalne dev-maszyny (DNS rebinding) ⇒ eksfiltracja dokumentów/projektów R&D.
  • Ryzyko compliance: naruszenia izolacji danych, IP leakage, utrata integralności modeli.

Rekomendacje operacyjne / co zrobić teraz

1) Patch & wersje

  • NVIDIA: zaktualizuj Container Toolkit → 1.17.8, GPU Operator → 25.3.2, Device Plugin → 0.17.3, MIG Manager → 0.12.2. Dla OpenShift – użyj tagów v1.17.8-ubi8 / v0.12.2-ubi9. Jeśli używasz crun – 23266 nie dotyczy, ale 1.17.7 nadal wymaga łat na 23267.
  • Ollama: zaktualizuj do wersji usuwających CVE-2024-37032 i CVE-2025-51471 (sprawdź release notes projektu). Minimalnie ≥ v0.1.34 dla „Probllama”, naprawa 0.6.7-related dla token-steal.

2) Minimalizacja ekspozycji

  • Nie wystawiaj API Ollama publicznie. Jeśli musisz – wymuś reverse proxy z auth (OIDC/Basic) i TLS:
# Nginx (skrót)
server {
  listen 443 ssl http2;
  server_name ollama.example.com;
  ssl_certificate ...; ssl_certificate_key ...;

  auth_basic "Restricted";              # tymczasowo
  auth_basic_user_file /etc/nginx/.htpasswd;

  location / {
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:11434;
  }
}

(Wiz podkreśla brak natywnego auth w wielu wdrożeniach; reverse proxy to „must”.)

  • W instancjach lokalnych wymuś bind tylko do loopback:
# Linux (systemd override)
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=127.0.0.1"

3) Twardnienie kontenerów i K8s

  • Zabroń --privileged i host-mountów; używaj rootless (jeśli możliwe), seccomp/apparmor i redukcji capabilities:
# PodSecurityContext (skrócone)
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile: { type: RuntimeDefault }
  capabilities: { drop: ["ALL"] }
  • Segmentuj sieć przy pomocy NetworkPolicy – oddziel inference od reszty:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-only-proxy, namespace: ai }
spec:
  podSelector: { matchLabels: { app: ollama } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { name: ingress } }
      ports: [{ protocol: TCP, port: 11434 }]

4) Rejestry modeli i „model supply chain”

  • Pin’uj hashy warstw, weryfikuj źródła (allow-list domen/rejestrów), skanuj artefakty przed „pull”. (W RCE „Probllama” wektor przechodził przez /api/pull z prywatnego rejestru.)

5) Detekcja i IR

  • Wskaźniki podejrzanej aktywności (przykłady):
    • Nietypowe żądania /api/pull z zewnętrznych adresów, 4xx/5xx na /api/push, powtarzające się tworzenie modelu z niestandardowymi FROM.
    • W nodach GPU: logi runtime wskazujące na modyfikacje ld.so.preload, anomalie w hookach OCI, nieautoryzowane biblioteki preload (23266/23267).
  • Reguły (przykład Falco):
- rule: Write to ld.so.preload
  desc: Potential container escape via ld.so.preload manipulation
  condition: >
    evt.type in (open, openat) and fd.name = "/etc/ld.so.preload" and
    proc.name not in (ldconfig)
  output: "Process %proc.name wrote to ld.so.preload (user=%user.name container=%container.id)"
  priority: CRITICAL

Różnice / porównania z innymi przypadkami

  • Ollama – błędy głównie na styku API i walidacji danych (path traversal, token-steal, DNS rebinding), a więc ataki zdalne poprzez HTTP i łańcuchy z udziałem przeglądarek/serwerów proxy.
  • NVIDIA Container Toolkit/GPU Operator – błędy w hookach OCI i przepływie inicjalizacji, skutkujące eskalacją z kontenera do hosta (breakout), co zagraża całemu węzłowi i sąsiadującym workloadom.

Podsumowanie / kluczowe wnioski

  1. Zaktualizuj wszystko, co dotyczy stosu AI – najpierw Toolkit 1.17.8 / GPU Operator 25.3.2, potem Ollama do wersji z łatami na RCE, rebinding i token-exposure.
  2. Nie wystawiaj surowych endpointów inferencji do Internetu; dodaj auth i TLS na brzegu.
  3. Odchudź uprawnienia kontenerów, stosu