Podatności MLflow

W wersjach MLflow przed 3.9.0 występuje podatność typu Server-Side Request Forgery (SSRF). Funkcja `_create_webhook()` akceptuje parametr `url` kontrolowany przez użytkownika bez walidacji, co pozwala atakującemu na wymuszenie wysyłania żądań HTTP do wewnętrznych usług lub zewnętrznych serwerów.

W MLflow w wersjach od 3.12.0rc0 do 3.17.0 deserializacja scorerów zewnętrznych w mlflow/genai/scorers/base.py akceptuje klasy potomne modułów z listy dozwolonych zamiast wymagać dokładnie dozwolonego modułu. Atakujący może umieścić moduł Pythona w zapisywalnym pakiecie dozwolonym i wywołać go przez endpoint /ajax-api/3.0/mlflow/scorer/invoke, co prowadzi do wykonania kodu. Wersja 3.17.0 naprawia problem.

Podatność w MLflow w wersjach do 3.10.1.dev0 umożliwia nieautoryzowany dostęp do endpointów przesyłania wieloczęściowego (MPU) przy włączonym trybie `--serve-artifacts`. Logika autoryzacji nie wymusza sprawdzania uprawnień na poziomie zasobów dla endpointów `/mlflow-artifacts/mpu/*`, co pozwala atakującym nadpisywać artefakty innych użytkowników. Może to prowadzić do nieautoryzowanego zapisu między użytkownikami, zatrucia łańcucha dostaw modeli oraz zdalnego wykonania kodu po załadowaniu skompromitowanych modeli.

W MLflow w wersji 3.9.0 funkcja Asystenta MLflow zawiera podatność polegającą na nieprawidłowej walidacji pochodzenia żądań w punktach końcowych /ajax-api. Umożliwia to zdalnemu atakującemu wykorzystanie żądań międzyoriginowych ze złośliwej strony internetowej do interakcji z Asystentem MLflow działającym na lokalnym komputerze ofiary.

W mlflow/mlflow endpointy FastAPI dla zadań pod `/ajax-api/3.0/jobs/*` nie są chronione uwierzytelnianiem ani autoryzacją, gdy włączona jest aplikacja `basic-auth`. Nawet jeśli włączono uwierzytelnianie podstawowe, każdy klient sieciowy może bez poświadczeń przesyłać, odczytywać, wyszukiwać i anulować zadania.

W MLflow w wersji 3.8.0 wykryto podatność na wstrzykiwanie poleceń w kodzie inicjalizującym kontener serwowania modeli. Funkcja `_install_model_dependencies_to_env()` bezpośrednio interpoluje zależności z pliku `python_env.yaml` do polecenia powłoki bez sanityzacji, co umożliwia atakującemu wykonanie dowolnych poleceń poprzez dostarczenie złośliwego artefaktu modelu.

W bibliotece mlflow przed wersją 3.7.0 wykryto podatność na ścieżkę przejścia (path traversal) w funkcji `extract_archive_to_dir`. Brak walidacji ścieżek wewnątrz archiwum tar pozwala atakującemu na nadpisanie dowolnych plików lub eskalację uprawnień.

Podatność w procesie ekstrakcji pyfunc w MLflow umożliwia zapis dowolnych plików z powodu nieprawidłowego obsługiwania wpisów archiwum tar. Użycie `tarfile.extractall` bez walidacji ścieżki pozwala spreparowanym plikom tar.gz zawierającym `..` lub ścieżki absolutne na opuszczenie docelowego katalogu ekstrakcji.

W MLflow występuje podatność polegająca na słabych wymaganiach dotyczących haseł, umożliwiająca obejście uwierzytelniania. Atakujący nie musi się uwierzytelniać; problem wynika ze słabych wymagań dotyczących haseł i może zostać wykorzystany do obejścia uwierzytelniania w systemie.

MLflow to otwarta platforma inżynierii AI dla agentów, dużych modeli językowych i modeli uczenia maszynowego. Od wersji 2.19.0 do 3.17.0 mlflow.crewai.autolog() rejestruje obiekty CrewAI Agent bez konsekwentnej sanityzacji zagnieżdżonych wartości zawierających poświadczenia. mlflow/crewai/autolog.py::_get_agent_attributes() konwertuje pole Agent llm na ciąg znaków zawierający klucz API dostawcy, podczas gdy mlflow/crewai/autolog.py::_construct_full_inputs() rozwija obiekt Agent do mlflow.spanInputs. Aplikacje mogą zatem wysyłać jawne poświadczenia dostawcy do backendu śledzenia MLflow lub skonfigurowanego miejsca docelowego OTLP, gdzie czytelnicy śladów mogą je uzyskać. Problem został naprawiony w wersji 3.17.0.

MLflow to otwarta platforma inżynierii AI dla agentów, dużych modeli językowych i modeli uczenia maszynowego. Od wersji 3.10.0 do 3.17.0 gałąź prompt w _create_model_version() akceptuje względne źródła bez schematu, ponieważ walidacja ścieżki jest uruchamiana tylko wtedy, gdy źródło ma schemat URL, a mlflow.prompt.is_prompt jest interpretowane przez obecność tagu, a nie przez prawdziwą wartość. Zdalny wywołujący może zapisać lokalną ścieżkę serwera jako lokalizację artefaktu wersji modelu i użyć /api/2.0/mlflow/model-versions/get-artifact do odczytu plików dostępnych dla procesu serwera MLflow. Domyślne nieuwierzytelnione serwery nie wymagają uprawnień, podczas gdy wdrożenia z podstawowym uwierzytelnianiem są narażone na użytkowników uwierzytelnionych, którzy mogą tworzyć zarejestrowane modele. Problem został naprawiony w wersji 3.17.0.

MLflow od wersji 3.12.0rc0 do 3.17.0 w endpointach scorer invoke, register i GenAI evaluate (w tym nieuwierzytelniony POST /ajax-api/3.0/mlflow/scorer/invoke) przyjmuje serializowane dane zewnętrznych scorerów, które Scorer.model_validate_json rozwiązuje za pomocą listy dozwolonych ścieżek modułów bez ograniczenia wybranej klasy lub argumentów konstruktora; przy zainstalowanych trulens i trulens-providers-litellm atakujący może wymusić żądanie wychodzące do wybranego hosta z kontrolowanymi nagłówkami i treścią.

W MLflow 3.17.1 i wcześniejszych występuje podatność path traversal w backendzie śledzenia FileStore. Nieuwierzytelniony atakujący może przesłać spreparowany identyfikator trace zawierający sekwencje przejścia katalogów do endpointu POST /api/3.0/mlflow/traces, co pozwala zapisywać pliki trace_info.yaml, request_metadata i tag poza docelowym katalogiem eksperymentu (w granicach uprawnień procesu serwera). FileStore był domyślnym backendem przed MLflow 3.7.0, a później opcjonalnym.

Flavor statsmodel w MLflow, wersje od 2.1.0 do 3.14.0, całkowicie pomija kontrolę bezpieczeństwa MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False w funkcji _load_model(), co pozwala zdalnemu atakującemu na wykonanie dowolnego kodu poprzez spreparowany artefakt MLmodel.

Flavor dspy w MLflow w wersjach >= 2.0 stosuje kontrolę bezpieczeństwa MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False tylko wtedy, gdy model_path kończy się na .pkl, co pozwala zdalnemu atakującemu na wykonanie dowolnego kodu za pomocą spreparowanego artefaktu MLmodel.

Wykonanie kodu może wystąpić w wersjach platformy MLflow od wersji 0.0.1 lub nowszych, umożliwiając złośliwie spreparowanemu artefaktowi modelu wykonanie dowolnego kodu na systemie użytkownika końcowego po załadowaniu przez projekt.

MLflow przed wersją 3.15.0 zawiera podatność, która pozwala uwierzytelnionym użytkownikom na utworzenie wersji modelu odwołującej się do katalogu artefaktów innego użytkownika i odczytanie plików bez wymaganego uprawnienia READ.

MLflow to platforma AI typu open source. W wersjach od 3.13.0 do 3.15.0 brakuje LogInputs w BEFORE_REQUEST_HANDLERS w pakiecie mlflow/server/auth, co pozwala każdemu uwierzytelnionemu użytkownikowi na wywołanie POST /api/2.0/mlflow/runs/log-inputs dla cudzego run_id i wstrzyknięcie rekordów DatasetInput do metadanych lineage dataset_inputs bez uprawnienia UPDATE. Problem naprawiono w wersji 3.15.0.

AI Gateway w MLflow akceptuje wartość auth_config.api_base podczas tworzenia sekretu bramki (mlflow/server/handlers.py, _create_gateway_secret) bez walidacji schematu, hosta lub zakresu IP; wartość jest przechowywana dosłownie. Endpoint proxy bramki (mlflow/server/gateway_api.py, raw_proxy) następnie wysyła żądanie HTTP do tego zapisanego api_base plus ścieżkę dostarczoną przez wywołującego i zwraca pełną treść odpowiedzi.

W MLflow w wersjach przed 3.14.0, przy włączonym uwierzytelnianiu, punkty końcowe API śledzenia (trace) nie mają odpowiednich walidatorów autoryzacji. Pozwala to każdemu uwierzytelnionemu użytkownikowi na ominięcie kontroli autoryzacji na poziomie eksperymentu dla wszystkich operacji na śladach, w tym odczytu, usuwania i modyfikacji śladów w eksperymentach, do których nie ma uprawnień. Problem wynika z procedury `_before_request`, która nie rejestruje walidatorów autoryzacji dla punktów końcowych śledzenia, co powoduje, że żądania są przetwarzane bez walidacji.

W MLflow do wersji 4666cffc7912ea606d592fc38d6a75e2935f65e7 wykryto brak autoryzacji w API CRUD dla schematów etykiet w zakresie eksperymentu. Luka umożliwia zdalne manipulowanie danymi bez odpowiedniego uwierzytelnienia, choć jej wykorzystanie jest trudne ze względu na wysoką złożoność ataku.

W MLflow do wersji 3.10.0 wykryto wadę w funkcji mlflow.data.digest_utils, która powoduje użycie słabej funkcji skrótu. Atak jest możliwy lokalnie, ma wysoką złożoność i jest trudny do wykorzystania, ale exploit został opublikowany.

Podatność w mlflow/mlflow przed wersją 3.11.0 umożliwia rozwiązywanie zmiennych środowiskowych w sekretach AI Gateway. Może to prowadzić do wycieku wrażliwych danych uwierzytelniających serwera do kontrolowanego przez atakującego punktu końcowego.

MLflow 3.9.0 z włączonym basic-auth nie sprawdza autoryzacji dla endpointów API Gateway: ListGatewaySecretInfos, ListGatewayEndpoints i ListGatewayModelDefinitions. Każdy uwierzytelniony użytkownik, niezależnie od uprawnień, może wyliczyć wszystkie sekrety bramy, konfiguracje endpointów i definicje modeli.

W mlflow/mlflow do wersji 3.9.0 brakuje kontroli dostępu dla endpointów SearchModelVersions REST API i GraphQL, co pozwala każdemu uwierzytelnionemu użytkownikowi na wyliczenie wszystkich wersji modeli. Problem został naprawiony w wersji 3.10.0.

W mlflow/mlflow przed wersją 3.11.0 funkcje tworzące tymczasowe katalogi ustawiają niebezpieczne uprawnienia (0o777 i 0o770). Pozwala to lokalnemu atakującemu na manipulację artefaktami modeli, co przy deserializacji przez cloudpickle może prowadzić do zdalnego wykonania kodu.

Podatność w mlflow/mlflow w wersjach 3.9.0 i wcześniejszych umożliwia nieuwierzytelnionemu atakującemu zdalne odczytanie dowolnych plików z systemu plików serwera. Problem występuje, gdy żądanie CreateModelVersion zawiera tag mlflow.prompt.is_prompt, co omija walidację ścieżki źródłowej. Funkcja get_model_version_artifact_handler() później wykorzystuje tę ścieżkę do serwowania plików bez weryfikacji statusu promptu modelu, prowadząc do całkowitego naruszenia poufności.

W mlflow/mlflow występuje podatność na wstrzyknięcie poleceń powłoki podczas serwowania modelu z włączoną opcją `enable_mlserver=True`. Parametr `model_uri` jest bezpośrednio osadzany w poleceniu powłoki wykonywanym przez `bash -c` bez odpowiedniego oczyszczania, co pozwala na wykonanie dowolnych poleceń przez atakującego.

W najnowszej wersji mlflow/mlflow, gdy włączona jest aplikacja `basic-auth`, punkty końcowe śledzenia i oceny nie są chronione przez walidatory uprawnień. Pozwala to każdemu uwierzytelnionemu użytkownikowi, w tym tym z uprawnieniami `NO_PERMISSIONS` na eksperymencie, na odczyt informacji o śladach i tworzenie ocen dla śladów, do których nie powinien mieć dostępu. Podatność wpływa na poufność poprzez ujawnienie metadanych śladów oraz na integralność poprzez umożliwienie nieautoryzowanego tworzenia ocen.

W mlflow/mlflow przed wersją 3.7.0 wykryto podatność na wstrzykiwanie poleceń w pliku `mlflow/sagemaker/__init__.py`. Atakujący może dostarczyć złośliwą nazwę obrazu kontenera przez parametr `--container`, która jest bezpośrednio interpolowana do poleceń powłoki wykonywanych przez `os.system()`, co umożliwia wykonanie dowolnych poleceń.

Podatność w MLflow umożliwia zdalne ominięcie uwierzytelniania z powodu użycia domyślnych, zakodowanych na stałe poświadczeń w pliku basic_auth.ini. Atak nie wymaga uwierzytelnienia i może prowadzić do wykonania dowolnego kodu w kontekście administratora.

Podatność w MLflow Tracking Server umożliwia zdalne wykonanie kodu poprzez atak typu directory traversal na obsługę ścieżek plików artefaktów. Luka wynika z braku walidacji ścieżek dostarczanych przez użytkownika przed użyciem ich w operacjach na plikach. Atak nie wymaga uwierzytelnienia.