Złośliwa strona może zatruć lokalny model AI w NVIDIA NemoClaw

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili podatność w środowisku NVIDIA NemoClaw, która w określonych konfiguracjach umożliwia złośliwej stronie internetowej uzyskanie nieautoryzowanego dostępu do lokalnej instancji Ollama obsługującej agenta AI. Najpoważniejszym aspektem problemu nie jest jednorazowe wysłanie niepożądanego żądania, lecz możliwość trwałego „zatrucia” modelu przez zmianę szablonu czatu, wpływającego na sposób przekazywania instrukcji systemowych i użytkownika do inferencji.

W skrócie

Słabość dotyczy integracji NemoClaw z lokalnym backendem Ollama w sytuacji, gdy usługa nasłuchuje na adresie 0.0.0.0:11434 i nie jest odpowiednio odseparowana od przeglądarki lub zabezpieczona warstwą pośredniczącą. Atak może wykorzystywać technikę DNS rebinding, aby skłonić przeglądarkę ofiary do komunikacji z lokalnym API.

atakujący może uzyskać dostęp do lokalnego API Ollama z poziomu przeglądarki,
możliwa jest modyfikacja właściwości modelu, w tym szablonu czatu,
ukryte instrukcje mogą być automatycznie dołączane do kolejnych interakcji z agentem,
dla macOS i Linuksa poprawka miała zostać wdrożona w NemoClaw v0.0.35,
wariant Windows/WSL w momencie opisu problemu nie był w pełni objęty poprawką.

Kontekst / historia

NemoClaw to otwarty stos referencyjny NVIDIA przeznaczony do uruchamiania agentów AI w kontrolowanym środowisku, z obsługą lokalnych serwerów inferencyjnych takich jak Ollama. Założeniem tej architektury jest umożliwienie pracy z lokalnymi modelami bez konieczności przekazywania danych do zewnętrznych usług chmurowych.

Opisany przypadek wpisuje się jednak w szerszą klasę zagrożeń związanych z lokalnymi usługami AI wystawionymi poza interfejs loopback. Wcześniej podobny problem opisano w kontekście Ollama jako CVE-2024-28224, gdzie wskazano ryzyko wykorzystania DNS rebinding do osiągnięcia lokalnej aplikacji z poziomu przeglądarki. Najnowsze ustalenia pokazują, że nawet znane wcześniej zagrożenie może powrócić, jeśli warstwa integracyjna wdraża lokalny backend w sposób osłabiający separację bezpieczeństwa.

Analiza techniczna

Kluczowym elementem podatności jest konfiguracja, w której Ollama uruchamiana jest z parametrem OLLAMA_HOST=0.0.0.0:11434. Taki sposób bindowania sprawia, że usługa nasłuchuje na wszystkich interfejsach sieciowych, zamiast pozostawać ograniczoną do 127.0.0.1. W bezpieczniejszym modelu backend powinien być dostępny wyłącznie lokalnie albo wystawiany przez reverse proxy z dodatkowymi mechanizmami autoryzacji.

Problem pogłębia fakt, że API Ollama nie wymaga natywnego uwierzytelniania. Ochrona opiera się więc na warstwach pośrednich, takich jak walidacja nagłówków Host i Origin oraz ograniczenia CORS. Jeśli jednak usługa jest osiągalna poza loopback, mechanizmy te mogą nie zapewnić skutecznej obrony przed żądaniami inicjowanymi z przeglądarki.

W scenariuszu DNS rebinding ofiara najpierw odwiedza domenę kontrolowaną przez napastnika, która początkowo rozwiązuje się do serwera zewnętrznego. Następnie rekord DNS tej samej domeny zostaje zmieniony tak, aby wskazywał na adres lokalny ofiary, na przykład 127.0.0.1. Dla przeglądarki pochodzenie pozostaje to samo, mimo że ruch zaczyna trafiać do lokalnej usługi. W efekcie możliwe staje się przesyłanie żądań do API Ollama tak, jakby były częścią legalnej sesji webowej.

Po uzyskaniu dostępu do API atakujący może przejść od zwykłego prompt injection do znacznie groźniejszego etapu, czyli trwałej modyfikacji szablonu czatu. Szablon ten definiuje sposób renderowania komunikatów do formy wejściowej dla modelu. Jeżeli zostanie rozszerzony o ukryte instrukcje, każde kolejne zapytanie kierowane do modelu może być automatycznie wzbogacane o polecenia kontrolowane przez napastnika. To sprawia, że manipulacja staje się trudniejsza do zauważenia, ponieważ dotyczy właściwości modelu, a nie pojedynczej rozmowy.

Dodatkowe wyzwanie dotyczy różnic architektonicznych między systemami. Dokumentacja NVIDIA wskazuje, że na typowych hostach innych niż WSL Ollama powinna działać na 127.0.0.1:11434, a komunikacja z sandboxem powinna przechodzić przez reverse proxy na 0.0.0.0:11435 z kontrolą tokenu. W środowiskach Windows/WSL sytuacja jest bardziej złożona, ponieważ kontener działający w WSL2 nie ma prostego dostępu do loopback hosta Windows, co może skłaniać do wystawiania usługi na wszystkich interfejsach.

Konsekwencje / ryzyko

Ryzyko nie sprowadza się wyłącznie do klasycznego „dostępu do localhost”. W tym przypadku przejęcie lokalnego backendu AI może skutkować kompromitacją logiki działania całego agenta. Jeśli agent ma dostęp do plików, terminala, narzędzi lokalnych, danych użytkownika lub integracji z usługami zewnętrznymi, zatruty model może wpływać na decyzje operacyjne podczas kolejnych zadań.

trwałe wstrzyknięcie ukrytych instrukcji do procesu inferencji,
manipulacja odpowiedziami modelu bez widocznych zmian w interfejsie,
możliwość nadużycia uprawnień agenta i jego narzędzi,
obejście założeń bezpieczeństwa opartych wyłącznie na sandboxingu,
utrudnione wykrywanie incydentu z powodu modyfikacji warstwy modelu.

W praktyce oznacza to, że nawet poprawnie odseparowane środowisko wykonawcze nie eliminuje ryzyka przejęcia samej logiki agenta. Jeżeli model podejmuje decyzje w oparciu o skażony szablon, skutki mogą obejmować zarówno błędne odpowiedzi, jak i nieautoryzowane działania wykonywane przez dostępne narzędzia.

Rekomendacje

Organizacje i użytkownicy korzystający z NemoClaw oraz Ollama powinni potraktować ten problem jako zagrożenie architektoniczne dotyczące lokalnych wdrożeń AI. Ograniczenie ryzyka wymaga połączenia hardeningu usług, kontroli dostępu i monitorowania integralności konfiguracji.

ograniczyć nasłuch Ollama do 127.0.0.1, jeśli architektura nie wymaga innego trybu pracy,
stosować reverse proxy z tokenem dostępu, kontrolą sesji oraz walidacją Host i Origin,
zaktualizować NemoClaw i komponenty zależne do najnowszych bezpiecznych wersji,
monitorować integralność szablonów czatu, manifestów i innych metadanych modeli,
wdrożyć mechanizmy ograniczające ataki z przeglądarki na lokalne usługi,
minimalizować uprawnienia agentów do plików, narzędzi i interfejsów sieciowych,
weryfikować po stronie aplikacji klienckiej, czy konfiguracja modelu nie została zmieniona.

Podsumowanie

Opisany problem pokazuje, że bezpieczeństwo lokalnych agentów AI zależy nie tylko od jakości modelu, ale również od sposobu udostępniania lokalnego serwera inferencyjnego. Połączenie ekspozycji na 0.0.0.0, braku silnego uwierzytelniania API i techniki DNS rebinding może doprowadzić do trwałego zatrucia modelu obsługującego agenta. Dla zespołów bezpieczeństwa to wyraźny sygnał, że lokalne wdrożenia LLM wymagają takich samych zasad hardeningu, monitoringu i kontroli integralności jak inne usługi o wysokim znaczeniu.