Ray 2.58.0 è stato pubblicato alle 05:42 UTC del 23 agosto. Tra le voci della sezione delle correzioni di Ray Serve compare una sola riga: correzione di ASGIService nella replica Serve che aggirava l’autenticazione token. Non è allegato alcun avviso di sicurezza, non è stato richiesto alcun CVE e non viene indicata alcuna gravità.

Che cosa dice la pull request

La PR #65189 è molto più esplicita del changelog. Il server gRPC interno nelle repliche Serve “era costruito con un semplice grpc.aio.server() e vincolato con add_insecure_port”, rendendolo, nelle parole dell’autore, l’unico server gRPC lato Python in Ray che saltava entrambi i controlli di trasporto di Ray. Con RAY_AUTH_MODE=token il servizio accettava richieste prive di credenziali valide e arrivava a pickle.loads(request.pickled_request_metadata) prima di eseguire qualsiasi convalida. Con RAY_USE_TLS=1, dove gli altri server gRPC Python di Ray usano mTLS, questa porta restava non cifrata.

Arrivare a pickle.loads prima della validazione è tutto il problema

Deserializzare un pickle fornito da un attaccante significa, per definizione, esecuzione di codice arbitrario: lo dice la documentazione stessa di Python. Qui conta l’ordine delle operazioni: il payload non fidato veniva deserializzato prima e autenticato dopo, rendendo l’autenticazione irrilevante su quel percorso, non semplicemente debole.

La distorsione: non un nuovo buco, ma una lacuna di cinque release

Ray ha introdotto l’autenticazione token descritta come estesa a tutti i componenti Ray nella 2.52.0. Questa porta non era coperta. Chiunque abbia attivato RAY_AUTH_MODE=token facendo affidamento su quella nota di release ha eseguito da allora un endpoint di deserializzazione non autenticato su ogni replica Serve. La correzione non aggiunge protezione; colma la distanza tra ciò che era documentato e ciò che era reale.

La correzione precede la release di diciotto giorni

La PR #65189 è stata integrata il 5 agosto. È arrivata agli operatori il 23 agosto, quando è stata pubblicata la 2.58.0. Per quei diciotto giorni la patch è rimasta leggibile in un repository pubblico mentre nessuna release la includeva — il costo standard di correggere apertamente un problema di sicurezza senza embargo, e il motivo per cui la riga del changelog conta più di quanto la sua posizione lasci intendere.

Che cosa dovrebbero verificare gli operatori

L’esposizione dipende dalla raggiungibilità di rete, poiché la porta si vincola su tutte le interfacce con una porta effimera. I cluster rilevanti sono quelli in cui le repliche Serve si trovano su una rete raggiungibile da chiamanti non fidati. L’aggiornamento sposta sia client sia server sui helper gRPC condivisi di Ray, che applicano gli interceptor e le impostazioni TLS già usati dal resto di Ray.