Podatności LMDeploy

InternLM LMDeploy w wersjach 0.9.0–0.18.0 zawiera podatność na nieuwierzytelnione zdalne wykonanie kodu. Atakujący może wysłać spreparowane dane pickle (base64) w polu serialized_named_tensors do endpointu /update_weights, które są deserializowane przez ForkingPickler.loads bez walidacji, co pozwala na wykonanie poleceń systemowych jako proces api_server.

LMDeploy w wersjach od 0.9.2 do 0.16.0 wykorzystywał funkcję recv_pyobj() do deserializacji komunikatów odbieranych przez gniazdo ZeroMQ PULL w płaszczyźnie sterowania DistServe/PD-disaggregation. Deserializacja pickle może wykonać dowolny kod, a adres peera był dostarczany przez endpoint HTTP POST /distserve/p2p_connect. Bez włączonego uwierzytelniania kluczem API atakujący mógł doprowadzić do zdalnego wykonania kodu z uprawnieniami procesu serwującego LMDeploy.

LMDeploy implementuje serwer RPC (AsyncRPCServer w zmq_rpc.py), który w funkcji call_and_response() deserializuje otrzymane wiadomości za pomocą pickles.loads() bez żadnej sanityzacji. Umożliwia to zdalne wykonanie kodu przez ten serwer RPC. Podatność występuje od wersji 0.9.1 do 0.10.2, gdzie została naprawiona.

LMDeploy deserializuje komunikaty peer-to-peer w trybie disaggregated serving za pomocą pickle. Funkcja handle_zmq_recv w lmdeploy/pytorch/disagg/conn/engine_conn.py odczytuje żądania cache-free przez recv_pyobj(), co deserializuje odebrane bajty przez pickle.loads(), a sprawdzenie isinstance przeciwko DistServeCacheFreeRequest następuje dopiero po zakończeniu deserializacji. Peer dostarczający te bajty jest kontrolowany przez wywołującego: p2p_connect przekazuje remote_engine_endpoint_info.zmq_address z treści żądania do connect() na gnieździe ZMQ PULL, a endpointy POST /distserve/p2p_initialize i /distserve/p2p_connect w lmdeploy/serve/openai/api_server.py nie stosują uwierzytelniania, chyba że serwer jest uruchomiony z api_keys, które domyślnie mają wartość None. Zdalny atakujący może skierować silnik do pobierania z kontrolowanego przez siebie punktu końcowego ZMQ i wykonać dowolny kod w procesie silnika. Wdrożenia, które nie włączają disaggregated serving, nie są dotknięte, ponieważ pętla odbioru jest uruchamiana tylko po zaakceptowaniu połączenia przez backend migracji.

LMDeploy w wersjach 0.12.1 do 0.12.2 zawiera lukę wstrzyknięcia kodu w pliku lmdeploy/pytorch/config.py w linii 620. Atakujący może wykonać dowolny kod Python, publikując złośliwy model HuggingFace ze spreparowaną wartością quantization_config.quant_dtype, która jest przekazywana do eval() bez walidacji.

InternLM LMDeploy do wersji 0.17.0 w trybie rozdzielenia prefill/decode DistServe nie zwalnia sesji schedulera, ponieważ proxy używa identyfikatorów sesji widocznych dla użytkownika zamiast wewnętrznych kluczy schedulera. Nieuwierzytelnieni atakujący mogą wysyłać żądania ukończenia do endpointu proxy, co kumuluje niezwolnione metadane i pamięć aż do zabicia workera prefill przez brak pamięci.

Podatność SSRF w LMDeploy do wersji 0.14.0 (załatana w commit 03c3130) w funkcji _load_http_url w connection.py. Mechanizm ochrony przed adresami prywatnymi sprawdza tylko oryginalny URL, nie weryfikując hostów po przekierowaniach HTTP.

LMDeploy to zestaw narzędzi do kompresji, wdrażania i serwowania dużych modeli językowych. W wersjach 0.12.3 i wcześniejszych, zakodowane na stałe "trust_remote_code=True" umożliwia zdalne wykonanie kodu (RCE) w łańcuchu dostaw HF bez zgody użytkownika. Wersja 0.13.0 naprawia ten problem.

LMDeploy w wersjach do 0.12.3 zawiera zakodowane na stałe ustawienie "trust_remote_code=True" w wielu miejscach ładowania modeli HuggingFace, co umożliwia zdalne wykonanie dowolnego kodu. W chwili publikacji nie są dostępne żadne publiczne łatki.

LMDeploy przed wersją 0.11.1 zawiera podatność na niebezpieczną deserializację, ponieważ funkcja torch.load() jest wywoływana bez parametru weights_only=True podczas ładowania plików kontrolnych modelu. Umożliwia to atakującemu wykonanie dowolnego kodu na maszynie ofiary, gdy ta załaduje złośliwy plik .bin lub .pt.