GH Actions - Cache Poisoning
Per ulteriori dettagli controlla il post originale https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
L'azione Git action/cache introduce un meccanismo di caching nel processo di Continuous Integration (CI), comprendente due fasi critiche:
Esegui Azione: Questa fase comporta la ricerca e il recupero dei dati memorizzati nella cache durante l'esecuzione della CI. La ricerca utilizza una chiave di cache unica, producendo due risultati:
Cache-hit: I dati richiesti vengono trovati nella cache e quindi recuperati per un uso immediato.
Cache-miss: Nessun dato corrispondente viene trovato nella cache, portando a un nuovo download dei file e delle directory richieste, simile a una richiesta per la prima volta.
Azione Post Workflow: Questa fase è dedicata alla memorizzazione nella cache dei dati dopo il workflow CI. In particolare, se si verifica un cache-miss durante l'azione di esecuzione, lo stato attuale delle directory specificate viene memorizzato nella cache utilizzando la chiave fornita. Questo processo è automatizzato e non richiede invocazione esplicita.
Misure di Sicurezza: Isolamento della Cache e Restrizioni di Accesso
Per mantenere la sicurezza e garantire l'isolamento della cache, vengono applicate restrizioni di accesso, creando una separazione logica tra i diversi rami. Ad esempio, una cache creata per il ramo Feature-A (con base nel ramo principale) sarà inaccessibile a una richiesta pull per il ramo Feature-B (anch'esso basato nel ramo principale).
L'azione di cache segue un ordine di ricerca specifico:
Prima cerca i cache hit all'interno dello stesso ramo dell'esecuzione del workflow.
Se non ha successo, estende la ricerca al ramo padre e ad altri rami upstream.
È importante notare che l'accesso alla cache è limitato al ramo, estendendosi a tutti i workflow e le esecuzioni di un ramo specifico. Inoltre, GitHub applica una politica di sola lettura per le voci di cache una volta create, vietando qualsiasi modifica.
Implicazione nel Mondo Reale: Da un Attacco a Workflow a Bassa Autorizzazione a uno ad Alta Autorizzazione
Uno scenario CI illustrativo dimostra come un attaccante potrebbe sfruttare il cache poisoning per elevare i privilegi da un workflow a bassa autorizzazione a uno ad alta autorizzazione:
Il workflow Unit-test, responsabile dell'esecuzione dei test unitari e degli strumenti di copertura del codice, si presume utilizzi uno strumento compromesso o vulnerabile. Questo workflow utilizza l'azione Git action/cache, rendendo la cache accessibile a qualsiasi workflow.
Il workflow Release, incaricato di costruire e rilasciare l'artefatto dell'applicazione, ottimizza le proprie operazioni memorizzando nella cache le dipendenze di Golang.
In questo scenario, il workflow di unit-test introduce una voce di cache malevola sostituendo una legittima libreria di logging di Golang (`go
Last updated
