ShadowMQ – niebezpieczny wzorzec deserializacji pickle wykryty w wielu silnikach wnioskowania AI

Badacze bezpieczeństwa z Oligo Security wykryli szereg podatności pozwalających na zdalne wykonanie kodu w głównych frameworkach do wnioskowania sztucznej inteligencji. Luki bezpieczeństwa występują w produktach oferowanych przez Meta, NVIDIA, Microsoft, vLLM oraz SGLang. Problem tkwi w niebezpiecznej kombinacji ZeroMQ i deserializacji pickle w Pythonie. Co ciekawe, szczególną uwagę badaczy zwrócił nie sam fakt występowania podatności, tylko sposób jej propagacji.

TLDR:

• Badacze bezpieczeństwa z Oligo Security odkryli serię podatności w silnikach wnioskowania AI.
• Problem występuje w Meta Llama, NVIDIA TensorRT-LLM, Microsoft Sarathi Serve, Modular Max Server, vLLM oraz SGLang.
• We wszystkich systemach zaobserwowano ten sam niebezpieczny wzorzec – deserializację pickle przez ZeroMQ na niezabezpieczonych socketach wystawionych do sieci.
• Wykryty wzorzec został nazwany przez badaczy ShadowMQ.
• Podatność mogła skutkować wykonaniem nieautoryzowanego kodu na serwerze (RCE).
• Producenci opublikowali poprawki bezpieczeństwa.

Dla niewtajemniczonych, Oligo Security to izraelska firma zajmującą się cyberbezpieczeństwem aplikacji w czasie wykonywania (runtime application security). Siedziba firmy znajduje się w Tel Awiwie, a biura ulokowane są między innymi w Nowym Jorku i Palo Alto. Została założona przez trzech przyjaciół z dzieciństwa, którzy w swojej karierze zawodowej pełnili funkcje badawcze i kierownicze w elitarnych jednostkach cyberbezpieczeństwa. 

Szczegóły techniczne

ZeroMQV (ZMQ) jest biblioteką służącą do asynchronicznej wymiany komunikatów w aplikacjach rozproszonych i współbieżnych. Udostępnia gniazda (sockets), których zadaniem jest przenoszenie komunikatów zarówno wewnątrz procesu (in-process), jak i między procesami (inter-process). Warto podkreślić, że nazwa Zero odnosi się do braku potrzeby dedykowanego brokera wiadomości (serwera pośredniczącego w komunikacji) w przeciwieństwie do tradycyjnych systemów kolejkowania komunikatów. Biblioteka ZeroMQV jest dostępna dla wielu języków programowania i działa na większości systemów operacyjnych, co czyni ją częstym wyborem w ekosystemie AI i uczenia maszynowego. 

Wykryta przez badaczy podatność we frameworku Meta Llama, oznaczona identyfikatorem CVE-2024-50050 stanowiła pierwsze rozpoznane miejsce występowania problemu. Co prawda  została załatana we wrześniu 2024 r., jednak podatny kod zaobserwowano w wielu obecnych rozwiązaniach. Luka bezpieczeństwa występowała w metodzie recv_pyobj() w bibliotece ZeroMQ, odpowiedzilanej za deserializację danych przy pomocy modułu pickle w Pythonie. Fragment podatnego kodu został zaprezentowany poniżej.

Jak widać na powyższych listingach, komunikaty przesyłane przez użytkownika, przekazywane są bez sanityzacji, bezpośrednio do modułu pickle. Niesie to za sobą poważne konsekwencje, ponieważ jak powszechnie wiadomo, w przypadku deserializacji odpowiednio spreparowanych danych przy pomocy pickle, istnieje możliwość zdalnego wykonania kodu.

Ponadto, framework Meta Llama udostępniał przez sieć socket ZeroMQ, co stanowiło otwartą furtkę dla atakującego – wystarczyło wysłać spreparowany obiekt do podatnego API, żeby wykonać dowolny kod na serwerze. Sockety były domyślnie dostępne dla każdego, jeżeli aplikacja została uruchomiona bez dodatkowych wymagań związanych z uwierzytelnieniem. W praktyce oznacza to, że każdy kto znał adres IP i odkrył port usługi mógł połączyć się z socketem i wysłać spreparowane żądanie.

Analizując wykryty wzorzec, badacze z Oligo Security nadali mu nazwę ShadowMQ, czyli ukrytą lukę w warstwie komunikacyjnej, która przenosi się z jednego repozytorium do drugiego poprzez kopiowanie i wklejanie podatnego kodu. Oligo zgłosiło wykrytą lukę (CVE-2024-50050) firmie Meta we wrześniu 2024 r., która stosunkowo szybko wydała poprawkę bezpieczeństwa, zastępując niebezpieczne użycie pickle, serializacją opartą o JSON. 

Następnie, bazując na wykrytej luce bezpieczeństwa, przeprowadzono analogiczną analizę systemów czołowych graczy na rynku AI. W efekcie udało się wykryć ten sam typ podatności w:

• vLLM – CVE-2025-30165,
• NVIDIA TensorRT-LLM – CVE-2025-23254,
• Modular Max Server – CVE-2025-60455.

Producenci podeszli do tematu odpowiedzialnie i niezwłocznie rozpoczęli prace nad opracowaniem poprawek. NVIDIA TensorRT-LLM wdrożyła HMAC (Hash-based Message Authentication Code) jako domyślne zabezpieczenie dla wszystkich komunikatów wymienianych między procesami, opartych na socketach. Dane są podpisywane i nie są deserializowane przed weryfikacją podpisu. Zastrzeżono, że wyłączenie tej opcji spowoduje ponowne wprowadzenie podatności. 

Z kolei vLLM dokonał migracji na silnik wnioskowania V1, charakteryzujący się bezpieczniejszymi mechanizmami serializacji oraz komunikacji międzyprocesowej. 

Modular Max Server jest szczególnym przypadkiem, ponieważ odziedziczył podatną logikę kodów z dwóch niezależnych źródeł: vLLM oraz SGLang. W tym przypadku deweloperzy dokonali gruntownych modyfikacji kodu wdrażając bezpieczne mechanizmy serializacji (JSON lub msgpack z walidacja danych), usunięcie nieuwierzytelnionych gniazd ZMQ, wdrożenie bezpiecznych protokołów wymiany danych z walidacją oraz uwierzytelnieniem. 

Ponadto, biblioteka pyzmq niezależnie wydała własną poprawkę bezpieczeństwa i dodała wyraźne ostrzeżenie w dokumentacji o ryzyku związanym z używania metody recv_pyobj na danych pochodzących z niezaufanych źródeł.

Powyżej opisano tylko główne przypadki, w których podatności zostały wykryte i naprawione stosownymi poprawkami bezpieczeństwa. Warto zauważyć, że nie wszystkie projekty zostały w pełni zabezpieczone – np. Microsoft Sarathi-Serve nadal pozostaje podatny, a SGLang jedynie częściowo naprawił problem, tzn. główny i najgroźniejszy wektor ataku został zablokowany, jednak w dalszym ciągu mogą występować fragmenty kodu podatnego na tego typu zagrożenie.

Istnieje wysokie prawdopodobieństwo, że inne, mniej znane projekty również korzystały z podatnego kodu, a co za tym idzie w dalszym ciągu mogą być podatne. 

Zaprezentowana sytuacja obrazuje systemowy charakter problemu ShadowMQ i jego daleko idące konsekwencje. Implikacje są niepokojące, każdy kto deserializuje niezaufane dane mógł nieświadomie wprowadzić krytyczną lukę RCE do swojej aplikacji. 

Silniki wnioskowania są krytycznym elementem infrastruktury AI. Przejęcie jednego węzła może skutkować m.in.: 

• wykonaniem dowolnego kodu na serwerze/klastrze (RCE),
• kradzieżą modeli i danych treningowych,
• eskalacją uprawnień,
• przekształceniem klastra obliczeniowego w koparkę kryptowalut.

Niepokojący jest również fakt wykrycia przez badaczy bezpieczeństwa Oligo tysięcy odsłoniętych gniazd ZeroMQ dostępnych publicznie, które mogą być bezpośrednio powiązane z podatnymi klastrami wnioskowania. Heksadecymalny ciąg: FF 00 00 00 00 00 00 00 01 7F oznacza baner TCP, charakterystyczny dla gniazda ZMQ.

Mam podatny system, co dalej?

Zalecamy weryfikację posiadanej wersji oprogramowania i wdrożenie aktualnych poprawek bezpieczeństwa:

• Meta Llama Stack ≥ 0.0.41,
• NVIDIA TensorRT-LLM ≥ v0.18.2,
• vLLM ≥ v0.8.5,
• Modular Max Server ≥ v25.6.

Ponadto zalecamy ograniczenie używania pickle na danych pochodzących z niezaufanych źródeł oraz wdrożenie kryptograficznej weryfikacji przed deserializacją i TLS dla komunikacji korzystającej z ZeroMQ. W przypadku korzystania z projektów otwarto-źródłowych, sugerujemy każdorazowo przeprowadzać audyt bezpieczeństwa kopiowanego kodu.

​

Źródło: oligo.security, pyzmq.readthedocs.io 

~_secmike