The Pulse
Tre falle di gravità elevata in vLLM espongono i sistemi di serving ad attacchi remoti
Tre avvisi di sicurezza di gravità elevata relativi a vLLM descrivono rischi che si manifestano a determinate condizioni: dall’esecuzione di comandi tramite un’immagine EPS all’esaurimento della memoria nelle installazioni multimodali. Gli
AI.info Team · Scritto con l’IA · verificato ·
Un avviso di sicurezza di gravità elevata relativo a vLLM segnala che un’immagine caricata può portare all’esecuzione di comandi, ma solo sui server in cui è installata una versione vulnerabile di Ghostscript. Pubblicato il 20 ottobre, l’avviso assegna al problema un punteggio di 8,1 e indica che la versione di vLLM interessata è la 0.30.0; la 0.32.0 è indicata come versione corretta. Altri due avvisi di gravità elevata, pubblicati a ottobre, descrivono rischi di esaurimento della memoria da remoto nelle installazioni multimodali. In questi casi, l’attacco dipende dal modello e dall’endpoint resi disponibili dall’operatore.
I file EPS oltrepassano il confine del caricamento delle immagini
La falla segnalata il 20 ottobre riguarda il componente di vLLM che carica le immagini: passa a Pillow i byte dell’immagine fornita senza limitare i formati accettati. Il tipo MIME dichiarato nella richiesta non determina quale decoder elabori i byte: un file EPS etichettato come PNG può comunque essere riconosciuto come EPS e instradato verso il percorso di elaborazione di Pillow che usa Ghostscript. L’avviso descrive una catena in cui una vulnerabilità nota di Ghostscript, CVE-2024-29510, può quindi consentire l’esecuzione di comandi con i privilegi del processo vLLM.
L’avviso precisa:
«Lo sfruttamento richiede un percorso per le richieste che accetti immagini, un soggetto che possa accedervi in base ai criteri di autenticazione dell’installazione e una build vulnerabile di Ghostscript sull’host».
— jperezdealgaba, autore dell’avviso
Ghostscript non è una dipendenza dichiarata di vLLM: perché sia possibile eseguire comandi, occorre quindi un eseguibile vulnerabile fornito dall’host o dall’immagine usata per l’installazione. Secondo l’avviso, il comportamento del componente che carica le immagini è stato riprodotto con vLLM 0.30.0, ma il percorso della richiesta HTTP è stato ricostruito nel codice sorgente, non verificato dall’inizio alla fine. L’avviso non sostiene che si tratti di una nuova vulnerabilità di Ghostscript.
Altre due falle prendono di mira la memoria nelle installazioni multimodali
Un avviso del 6 ottobre distinto classifica come problema di gravità elevata, con un punteggio CVSS di 7,5, la possibilità di controllare mm_processor_kwargs tramite le richieste. Nei processori multimodali interessati, i client possono fornire valori come le dimensioni delle immagini o il numero di patch, ritagli o fotogrammi, che vLLM passa al codice del processore. Secondo l’avviso, una sola richiesta può provocare un’allocazione di memoria CPU o GPU sufficiente a far terminare il server API o un worker. Le versioni dalla 0.7.3 in poi sono indicate come interessate e la 0.31.0 come prima versione corretta.
Lo stesso avviso cita, tra gli altri, processori derivati da Isaac, InternVL e H2OVL, ma precisa che la debolezza riguarda il confine condiviso dell’input remoto, non un elenco fisso di modelli. La correzione proposta rifiuta per impostazione predefinita gli override non vuoti delle impostazioni del processore per singola richiesta. Gli operatori che servono client fidati possono scegliere esplicitamente di riabilitare questo comportamento, mentre restano disponibili la configurazione a livello di server e gli override dell’LLM in modalità offline.
Un secondo rapporto del 6 ottobre ha un ambito più ristretto: riguarda le installazioni di vLLM che servono MOSS-Audio. Secondo l’avviso, i client possono inviare impostazioni del processore diverse all’endpoint /tokenize, inducendo vLLM a conservare nuove istanze del processore e i relativi array di filtri mel. Impostazioni con valori eccessivamente grandi possono anche amplificare una singola allocazione; le versioni successive alla 0.24.0 e precedenti alla 0.31.0 sono indicate come interessate, mentre la 0.31.0 e quelle successive sono corrette.
Le chiavi API non proteggono ogni percorso
Il problema di MOSS-Audio mette in luce un dettaglio dell’installazione: secondo l’avviso, /tokenize non rientra tra i prefissi dei percorsi protetti dalla chiave API di vLLM, quindi impostare soltanto --api-key non ne limita l’accesso. Un reverse proxy che autentichi le richieste all’endpoint o ne limiti la frequenza può ridurre l’esposizione, precisa l’avviso.
Questi avvisi descrivono condizioni diverse, non un unico attacco applicabile a ogni installazione di vLLM. Il problema dei file EPS dipende da una versione specifica, da un percorso di elaborazione delle immagini e dalla presenza di software vulnerabile sull’host; gli altri due dipendono dalla gestione delle richieste multimodali e, nel caso della falla di MOSS-Audio, da un modello specifico e da un endpoint esposto. Gli operatori possono prendere come obiettivo concreto per l’aggiornamento le versioni corrette indicate: la 0.32.0 per l’avviso sui file EPS e la 0.31.0 per i due avvisi del 6 ottobre.