0xmrma/cve-2026-5061
Consul Template validava la destinazione di un symlink durante la valutazione del template, ma il successivo recupero delle dipendenze leggeva il percorso originale. Reindirizzare il link tra queste operazioni trasformava un riferimento a un file all'interno della sandbox in una divulgazione di file al di fuori della sandbox.
Consul Template ha convalidato dove puntava un symlink durante la valutazione del template, ma il successivo fetch della dipendenza leggeva il percorso originale. Ripuntare il collegamento tra queste due operazioni ha trasformato un riferimento a un file all'interno della sandbox in una divulgazione di file al di fuori della sandbox.
Ho trovato questo problema durante la revisione di HashiCorp Consul Template, con una domanda di sicurezza molto specifica in mente:
Se sandbox_path convalida un symlink durante la valutazione del template, la successiva lettura del file rimane vincolata allo stesso target convalidato?
In questo caso, la risposta è stata no.
L'helper di template file risolveva il percorso e applicava la sandbox configurata durante la valutazione del template. Ma dopo quel controllo, creava una dipendenza di file utilizzando il percorso grezzo originale.
Quella dipendenza veniva recuperata successivamente.
Se un attaccante ripuntava il symlink nell'intervallo tra la convalida e il fetch della dipendenza, Consul Template poteva leggere un file fuori dalla sandbox. Se il collegamento veniva ripristinato prima del rendering successivo, la convalida della sandbox passava di nuovo e il contenuto esterno memorizzato in cache veniva comunque renderizzato.
Quel problema è diventato CVE-2026-5061.
Bollettino HashiCorp: HCSEC-2026-12
Bollettino IBM: Bollettino di sicurezza CVE-2026-5061
CVE: CVE-2026-5061
Corretto in: 0.42.0
photo0
symlink in-sandbox controllato dall'attaccante -> la convalida della sandbox risolve un target sicuro -> la dipendenza memorizza il percorso grezzo originale -> l'attaccante ripunta il collegamento fuori dalla sandbox -> il fetch della dipendenza legge il file esterno -> l'attaccante ripristina il collegamento sicuro -> la convalida successiva passa -> il contenuto esterno in cache viene renderizzato
Consul Template è uno strumento di rendering di template per i dati di Consul e Vault.
Può essere eseguito in modo continuo, monitorare i cambiamenti delle dipendenze e renderizzare i dati in file o variabili d'ambiente per il consumo da parte delle applicazioni.
L'helper di template file legge un file locale e inserisce il suo contenuto nell'output renderizzato.
Poiché la lettura di file locali può esporre segreti leggibili dal processo, Consul Template fornisce sandbox_path come confine per questo helper.
La proprietà di sicurezza documentata è semplice:
file devono trovarsi all'interno della sandbox configurataQuesto rende sandbox_path un vero confine di sicurezza.
La domanda importante non era se il percorso sembrava essere all'interno della sandbox.
La vera domanda era:
Il file che viene letto rimane lo stesso file che ha superato la convalida della sandbox?
Nelle versioni vulnerabili, non lo era.
Le sandbox dei filesystem falliscono spesso nello spazio tra la convalida del percorso e l'accesso al file.
Il pattern comune è:
Questa assunzione non è sicura quando un attaccante può modificare un symlink o una ridirezione equivalente del filesystem tra le due operazioni.
Consul Template rendeva questa superficie particolarmente interessante perché la valutazione del template e il fetch delle dipendenze erano fasi separate.
Quella separazione creava la giusta domanda di sicurezza:
Il fetch della dipendenza è vincolato al target convalidato, oppure risolve di nuovo il percorso controllato dall'attaccante?
Era quel confine su cui mi sono concentrato.
La causa principale era una discrepanza time-of-check to time-of-use tra:
template/funcs.godependency/file.goAlla revisione testata, fileFunc() faceva questo:
normalized := strings.TrimSpace(s)
err := pathInSandbox(sandboxPath, normalized)
if err != nil {
return "", err
}
d, err := dep.NewFileQuery(s)
L'helper di convalida risolveva correttamente i symlink prima di verificare l'appartenenza alla sandbox:
sandboxResolved, err := filepath.EvalSymlinks(filepath.Clean(sandbox))
targetResolved, err := filepath.EvalSymlinks(filepath.Clean(path))
rel, err := filepath.Rel(sandboxResolved, targetResolved)
if rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
return fmt.Errorf("'%s' is outside of sandbox", path)
}
Quindi il controllo della sandbox comprendeva il target risolto.
Ma quel target risolto veniva scartato.
NewFileQuery() memorizzava invece la stringa originale:
return &FileQuery{
stopCh: make(chan struct{}, 1),
path: s,
}, nil
Poi il fetch successivo della dipendenza leggeva di nuovo quel percorso:
data, err := os.ReadFile(d.path)
Questa è l'intera vulnerabilità.
Il codice controllava una risoluzione del filesystem e successivamente ne usava un'altra.
Perché un symlink è mutabile.
L'attaccante non deve far superare a un target fuori dalla sandbox il controllo pathInSandbox() direttamente.
Deve solo cambiare ciò a cui il percorso grezzo già approvato risolve dopo la convalida, ma prima che Fetch() esegua la lettura.
La sequenza è:
pathInSandbox()FileQuery registra il percorso grezzo del collegamentoos.ReadFile(d.path) risolve di nuovo il collegamentoQuell'ultimo passaggio è importante.
Ripristinare il collegamento sicuro non rimuoveva il segreto già recuperato dalla cache delle dipendenze.
La distinzione importante è il bypass di un controllo di sicurezza esplicito.
Non si trattava semplicemente di:
"il file è cambiato mentre Consul Template lo stava osservando"
Osservare i file per rilevarne i cambiamenti è un comportamento previsto.
Il vero problema era:
un percorso che superava la restrizione documentata della sandbox poteva successivamente essere usato per leggere un file fuori da quella sandbox
Si tratta di un fallimento diretto del confine di fiducia.
L'applicazione aveva già preso una decisione di sicurezza:
Ma il fetch successivo non era legato al target che giustificava quella decisione.
È questo che ha trasformato la normale mutabilità del filesystem in una vulnerabilità.
Ho creato un reproducer autonomo basato sull'esatta sequenza di valutazione e fetch della dipendenza.
La configurazione controllata utilizzava: