CVE-2023-46737 in cosign
Riassunto
di VulDB • 22/06/2026
Cosign è uno strumento di firma sigstore per contenitori OCI. Cosign è vulnerabile a un attacco di negazione del servizio (DoS) da parte di un registro controllato dall'attaccante. Un attaccante che controlla un registro remoto può restituire un elevato numero di attestazioni e/o firme a Cosign, causando l'innesco di un ciclo lungo in Cosign che si traduce in un attacco basato su dati infiniti (endless data attack). La causa radice risiede nel fatto che Cosign esegue un loop attraverso tutte le attestazioni recuperate dal registro remoto nella funzione `pkg/cosign.FetchAttestations`. L'attaccante deve compromettere il registro o effettuare una richiesta a un registro sotto il suo controllo. In tal caso, l'attaccante deve restituire un elevato numero di attestazioni nella risposta inviata a Cosign. Il risultato è che l'attaccante può indurre Cosign in un ciclo lungo o infinito, impedendo ad altri utenti di verificare i propri dati. Nel caso specifico di Kyverno (nota: il testo originale riporta "Kyvernos", presumibilmente refuso per Kyverno), un attaccante con privilegi limitati alla sola effettuazione di richieste al cluster può inviare una richiesta contenente un riferimento a un'immagine verso il proprio registro, innescare il ciclo infinito e negare ad altri utenti la possibilità di completare le proprie richieste di ammissione (admission requests). In alternativa, l'attaccante può ottenere il controllo del registro utilizzato da un'organizzazione e restituire un numero elevato di attestazioni anziché quello previsto. Il problema può essere mitigato in modo piuttosto semplice impostando un limite al numero massimo di attestazioni attraverso le quali Cosign eseguirà il loop. Tale limite non deve essere elevato per rientrare nella vastissima maggioranza dei casi d'uso, pur impedendo comunque l'attacco basato su dati infiniti. Questo problema è stato risolto nella versione 2.2.1 e si consiglia agli utenti di effettuare l'aggiornamento.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.