Odkrycie 221 luk bezpieczeństwa w popularnym frameworku vLLM ujawnia poważne ryzyko przepełnienia bufora GPU, które może być wykorzystane przez złośliwe modele. Ten problem podkreśla krytyczną potrzebę weryfikacji integralności danych w systemach AI, zwłaszcza w kontekście „Secure by Design”.
Analiza podatności w vLLM
Audyt kodu C++ i CUDA w vLLM wykazał 221 przypadków cichego obcinania 64-bitowych metadanych tensorów PyTorch do 32-bitowych liczb całkowitych. To obcięcie ma miejsce przed alokacją buforów GPU. Kluczowe aspekty podatności:
- Typ luki: Ciche obcinanie 64-bitowych metadanych tensorów PyTorch do 32-bitowych intów.
- Mechanizm ataku: W przypadku ścieżek kodu dla plików modeli GGUF, atakujący może kontrolować wymiary tensorów poprzez nagłówek pliku.
- Skutek: Deterministyczne przepełnienie bufora GPU, wywołane załadowaniem spreparowanego modelu.
- Liczba instancji: Zidentyfikowano 221 miejsc występowania problemu.
- Precedens: Ta sama klasa błędów została już udokumentowana w 10 CVE w projektach takich jak llama.cpp i Ollama.
- Status: Zgłoszenie do vLLM zostało zamknięte. Złożono propozycję CWE do MITRE w celu formalnego uznania tej klasy podatności.
Kontekst Rynkowy i Implikacje Bezpieczeństwa
W dobie rosnącej popularności modeli językowych i frameworków do ich obsługi, takich jak vLLM, kwestie bezpieczeństwa stają się priorytetem. Incydent ten uwypukla fundamentalne wyzwania związane z zarządzaniem pamięcią i integralnością danych w wysokowydajnych systemach obliczeniowych, zwłaszcza tych wykorzystujących GPU.
Podejście „Secure by Design” wymaga weryfikacji każdego etapu przetwarzania danych, od parsowania nagłówków plików po alokację zasobów, aby zapobiec lukom wynikającym z nieprawidłowej obsługi typów danych. Automatyzacja testów bezpieczeństwa i audytów kodu jest kluczowa dla wczesnego wykrywania tego typu problemów.
Materiał opracowany przez redakcję BitBiz na podstawie doniesień rynkowych.
Skomentuj Wiktor Anuluj pisanie odpowiedzi