Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#991 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
rust
Domínio
security

Direção de pesquisa

Comece em dstack/vmm/src/app/registry.rs, em extract_layer e no chamador download_and_extract_layers, depois inspecione dstack/crates/dstackup/src/image.rs, em extract, e compare com o caminho do verificador reforçado de #881. Defina a política de tipos de entrada das camadas OCI, o tratamento de membros ignorados, membros gzip, limites de tamanho e de quantidade de entradas e a limpeza; considera-se concluído quando os dois pontos de extração pela rede seguem um comportamento documentado e testado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Rust
Estrelas
561
Forks
99
Merge médio
1d 5h
PRs com merge (30d)
182

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Dstack-TEE/dstack

Todas as issues de Dstack-TEE/dstack

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.