Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Audit remaining network tar extraction sites (vmm OCI layers, dstackup) after #881

Aperta
#991 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
security

Direzione di ricerca

Inizia in dstack/vmm/src/app/registry.rs, in extract_layer e nel suo chiamante download_and_extract_layers, poi esamina dstack/crates/dstackup/src/image.rs, in extract, e confronta il percorso del verificatore hardenizzato di #881. Definisci la policy dei tipi di voce dei layer OCI, la gestione dei membri ignorati, dei membri gzip, dei limiti di dimensione e di numero di voci e della pulizia; il lavoro è completato quando entrambi i punti di estrazione dalla rete seguono un comportamento documentato e testato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

#881 hardened image archive extraction in dstack-verifier (download_image → extract_image_archive): entry paths are restricted to normal relative components, only regular files and directories are accepted, and tar::Entry::unpack_in confinement failures are treated as errors.

The same class of input — a tar archive fetched over the network and unpacked into a local directory — exists at two other call sites that #881 intentionally left out of scope. This issue tracks auditing them.

Call site 1: VMM OCI layer extraction (primary)

dstack/vmm/src/app/registry.rs:260 (extract_layer, reached from download_and_extract_layers at line 253):

let decoder = GzDecoder::new(data);
let mut archive = tar::Archive::new(decoder);
archive.unpack(dest).context("failed to extract gzipped tar layer")?;

This unpacks guest-image layers pulled from a container registry over the OCI Distribution API, before any measurement or signature check binds the content. Compared to the verifier path after #881:

  • No entry-type allowlist. Symlinks, hardlinks, character/block devices and FIFOs in a layer are materialised on the host. tar-rs only special-cases dir/symlink/hardlink; other node types fall through to the generic unpack path.
  • Escaping entries are silently skipped, not rejected. Archive::unpack calls Entry::unpack_in per entry and discards the bool, so a member containing .. is dropped without any error. The extraction reports success with a partial result. #881 explicitly turned this into a hard error for the verifier.
  • Single-member gzip only. flate2::read::GzDecoder stops at the first gzip member and returns clean EOF; tar::Archive then ends iteration with no error, so a multi-member layer extracts partially and silently. (Verified locally: a 2048-byte tar split across two concatenated gzip members yields 1024 bytes and 1 entry, err=None.)
  • Post-extraction cleanup is best-effort. The for dir in &["dev", "etc", "proc", "sys"] loop uses fs_err::remove_dir (non-recursive) and ignores the result, so a non-empty etc/ from a layer survives.

Mitigations that are already present, for the record: tar-rs unpack_in drops .. members, canonicalises the parent directory via validate_inside_dst before writing (so symlink-through-parent traversal is blocked), and masks setuid/setgid off unless set_preserve_permissions(true) is called. So this is a hardening/robustness gap and an unhelpful-failure-mode problem, not a known traversal vulnerability.

Note that this call site cannot simply reuse #881's rule set: container rootfs layers legitimately contain symlinks and whiteout entries, so it needs its own policy (e.g. an explicit type allowlist, erroring on skipped members, MultiGzDecoder, and a decompressed-size / entry-count cap) rather than a copy of the verifier logic.

Call site 2: dstackup (secondary)

dstack/crates/dstackup/src/image.rs:752 (extract) shells out to tar -xzf ... --no-same-owner --no-same-permissions. Ownership and permission carry-over are already handled and the intent is documented in a comment. Remaining gaps are symlink/hardlink members and the absence of a size cap. Lower priority than call site 1.

Suggested scope

  • Define and document the entry-type policy for OCI layer extraction in vmm.
  • Turn silently-skipped (escaping) members into an error.
  • Switch GzDecoder → MultiGzDecoder in extract_layer.
  • Bound decompressed size and entry count for network-fetched archives (also missing in the verifier path after #881).
  • Make the dev/etc/proc/sys cleanup explicit about what it does and does not remove, or drop it in favour of the type allowlist.

Refs: #881

Lingua principale
Rust
Stelle
555
Fork
97
Merge medio
1g 3h
PR unite (30g)
199

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Dstack-TEE/dstack

Tutte le issue di Dstack-TEE/dstack

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.