Fonctionnalités du cache KV distribué vLLM RHSB-2025-001 - (CVE-2025-47277)

Public Date: May 26, 2025, 23:32
Mis à jour May 26, 2025, 23:32 - Chinese, Simplified Anglais Japanese Korean

Est-ce que cette infomation vous a été utile ?

Ongoing État
Moderate Impact

 

Récapitulatif 

Le projet vLLM fournit une bibliothèque performante et facile à utiliser pour les Modèles de Langage LLM. Certaines fonctionnalités vLLM nécessitent une planification supplémentaire pour garantir un déploiement et une utilisation sécurisés. En particulier, la communication inter-nœuds dans vLLM n'est pas sécurisée par défaut et ne peut être protégée qu'en limitant les nœuds à un réseau isolé.

Une vulnérabilité a été découverte dans le projet vLLM. Le problème est attribué à CVE-2025-47277, avec un impact de gravité évalué à Modéré. Par défaut, les produits Red Hat sont configurés pour restreindre les nœuds vLLM à un réseau isolé. Cependant, cette vulnérabilité pourrait devenir pertinente si les clients modifient les configurations spécifiques et, par conséquent, les produits Red Hat sont affectés. 

Les produits Red Hat suivants incluent vLLM :

  • Red Hat AI Inference Server

  • Red Hat Enterprise Linux AI (RHEL AI)

  • Red Hat OpenShift AI (RHOAI)

Détails techniques

Configuration impactée

Les utilisateurs sont concernés si leur déploiement vLLM remplit toutes les conditions suivantes :

  1. Utilisation du moteur vLLM V0, qui était la valeur par défaut avant la version 0.8.0. Dans la version 0.8.0 et les versions ultérieures, vLLM doit être exécuté avec la variable d'environnement VLLM_USE_V1 définie sur 0. Il ne s’agit pas d’une configuration par défaut dans les produits Red Hat.

  2. Utilisation des versions affectées de vLLM avec la fonctionnalité PyNcclPipe avec le moteur V0 de 0.6.5 à 0.8.4, inclus. Il ne s’agit pas d’une configuration par défaut dans les produits Red Hat.

  3. Le nœud est connecté à des réseaux autres que le réseau de communication inter-nœuds vLLM isolé. Les produits Red Hat n'activent pas les fonctionnalités multi-nœuds dans leur configuration par défaut.

  4. S'appuyer sur le paramètre –kv-ip de KVTransferConfig pour empêcher le serveur vLLM de recevoir des données provenant de réseaux non approuvés. Il ne s’agit pas d’une configuration par défaut dans les produits Red Hat.

Aucune autre configuration, y compris les configurations par défaut des produits susmentionnés, n'est affectée. 

Contexte

vLLM peut être configuré pour s'exécuter dans un scénario multi-nœuds. Cela répartit l’exécution du modèle sur des GPU répartis sur plusieurs hôtes. Un autre mécanisme optionnel qui peut être utilisé dans un scénario multi-nœuds est la distribution et le partage du cache KV. 

Le moteur V0 dispose de plusieurs options expérimentales pour transférer le cache KV entre les hôtes. L’une de ces options, l’implémentation PyNcclPipe, est l’objet de cette vulnérabilité.

Les produits Red Hat n'activent pas les déploiements vLLM multi-nœuds par défaut. 

Risques associés

vLLM est un projet communautaire de la Fondation PyTorch. La philosophie de sécurité de vLLM, qui hérite de certains attributs clés de PyTorch, est décrite dans ce guide de sécurité. Le guide de sécurité décrit que les communications multi-nœuds doivent être isolées sur un réseau à usage unique. Cette philosophie met fortement l’accent sur l’optimisation des performances, où les administrateurs système sont responsables de garantir un environnement sécurisé.

Vulnérabilité PyNcclPipe

KVTransferConfig inclut un paramètre CLI --kv-ip destiné à permettre aux opérateurs de spécifier l'interface réseau à laquelle le cache KV doit se lier. Cependant, lors de l'utilisation de PyNcclPipe, ce paramètre est ignoré et se lie à la place à 0.0.0.0, l'exposant sur toutes les interfaces réseau. Dans les environnements où le nœud vLLM est connecté à plusieurs réseaux, y compris des réseaux non approuvés, ce comportement pourrait permettre à un attaquant sur un réseau non approuvé d'exécuter des commandes arbitraires sur le serveur.

Les produits Red Hat déploient vLLM dans des conteneurs dans des pods avec une seule interface réseau, éliminant ainsi la possibilité d'utiliser le paramètre –kv-ip comme méthode efficace pour restreindre l'accès. Les contrôles d'accès aux applications réseau dans un pod doivent être restreints à l'aide d'objets NetworkPolicy dans les environnements Openshift ou en créant des réseaux isolés dédiés à l'aide de podman.

Recommandations

Le transfert de cache KV dans le moteur V0 est expérimental et n'est pas recommandé pour une utilisation dans un environnement de production. Si vous êtes intéressé par ce type de fonctionnalité, nous vous encourageons à suivre les développements au sein du projet llm-d récemment annoncé.

Remerciements

Ce problème a été signalé indépendamment par trois parties différentes :

Références

Comments