W wersjach vLLM od 0.6.5 do 0.8.4, przy użyciu integracji `PyNcclPipe` z silnikiem V0, interfejs `TCPStore` wbrew zamierzeniu nasłuchiwał na wszystkich interfejsach sieciowych zamiast tylko na wskazanym prywatnym adresie IP. Stanowi to krytyczne zagrożenie, ponieważ pozwala nieuwierzytelnionemu atakującemu z sieci na przesyłanie dowolnych obiektów do deserializacji.
▸ Pokaż oryginał (EN)
vLLM, an inference and serving engine for large language models (LLMs), has an issue in versions 0.6.5 through 0.8.4 that ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected. vLLM supports the use of the `PyNcclPipe` class to establish a peer-to-peer communication domain for data transmission between distributed nodes. The GPU-side KV-Cache transmission is implemented through the `PyNcclCommunicator` class, while CPU-side control message passing is handled via the `send_obj` and `recv_obj` methods on the CPU side. The intention was that this interface should only be exposed to a private network using the IP address specified by the `--kv-ip` CLI parameter. The vLLM documentation covers how this must be limited to a secured network. The default and intentional behavior from PyTorch is that the `TCPStore` interface listens on ALL interfaces, regardless of what IP address is provided. The IP address given was only used as a client-side address to use. vLLM was fixed to use a workaround to force the `TCPStore` instance to bind its socket to a specified private interface. As of version 0.8.5, vLLM limits the `TCPStore` socket to the private interface as configured.
Mechanizm kontrolnych komunikatów CPU w klasie `PyNcclPipe` korzysta z metod `send_obj` i `recv_obj`, które opierają się na interfejsie `TCPStore` z biblioteki PyTorch. Zgodnie z domyślnym zachowaniem PyTorch, `TCPStore` wiąże gniazdo ze wszystkimi dostępnymi interfejsami sieciowymi, ignorując adres IP przekazany przez parametr `--kv-ip`. W efekcie interfejs przeznaczony wyłącznie dla sieci prywatnej był dostępny publicznie. Podatność sklasyfikowana jako CWE-502 (deserialization of untrusted data) oznacza, że atakujący może przesłać spreparowany obiekt, który zostanie zdeserializowany po stronie serwera.
Nieuwierzytelniony zdalny atakujący może przesłać złośliwy, zserializowany payload do interfejsu `TCPStore`, co może skutkować wykonaniem dowolnego kodu (RCE) na węźle inference, a w konsekwencji pełnym przejęciem systemu, naruszeniem poufności i integralności danych oraz dostępności usługi.
Należy zaktualizować vLLM do wersji 0.8.5 lub nowszej, w której `TCPStore` zostało naprawione tak, aby wiązało gniazdo wyłącznie ze wskazanym prywatnym interfejsem sieciowym. Do czasu aktualizacji należy bezwzględnie izolować węzły inference na poziomie sieci (firewall, segmentacja), aby interfejs `TCPStore` nie był dostępny z niezaufanych sieci, zgodnie z zaleceniami dokumentacji vLLM dotyczącymi bezpieczeństwa wdrożenia.
vLLM w wersjach od 0.6.5 do 0.8.4 — wyłącznie w konfiguracjach korzystających z integracji `PyNcclPipe` do transferu KV cache z silnikiem V0. Pozostałe konfiguracje nie są podatne.
Podatność dotyczy WYŁĄCZNIE środowisk używających integracji `PyNcclPipe` z silnikiem V0 — inne konfiguracje vLLM nie są narażone. Poprawka została wprowadzona poprzez wymuszenie bindowania gniazda `TCPStore` do określonego interfejsu prywatnego (commit 0d6e187e w repozytorium vllm-project/vllm).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HVllm
APPVllm0.6.5 – 0.8.5 (bez)
Powiązane podatności
Pominięcie uwierzytelnienia w vLLM — bypass klucza API OpenAI
vLLM: wyciek adresu sterty umożliwiający RCE przez endpoint multimodalny
RCE w vLLM poprzez deserializację pickle na niezabezpieczonych gniazdach ZeroMQ
RCE przez niebezpieczną deserializację w vllm MessageQueue.dequeue()
RCE przez niebezpieczną deserializację w vLLM z Mooncake (ZMQ/TCP)