Dstack-TEE / Dstack-TEE/dstack
Audit remaining network tar extraction sites (vmm OCI layers, dstackup) after #881
- Ngôn ngữ chính
- Rust
- Star
- 544
- Fork
- 96
- Merge trung bình
- 23 giờ 40 phút
- Pull request đã merge (30 ngày)
- 126
Mô tả
## 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):
```rust
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
Hướng dẫn đóng góp
Hướng nghiên cứu
Bắt đầu tại dstack/vmm/src/app/registry.rs ở extract_layer và hàm gọi nó là download_and_extract_layers, sau đó kiểm tra dstack/crates/dstackup/src/image.rs ở extract và so sánh với đường dẫn verifier đã được harden từ #881. Xác định policy về kiểu entry của OCI layer, cách xử lý các member bị bỏ qua, các member gzip, giới hạn kích thước và số lượng entry, cũng như việc dọn dẹp; hoàn thành khi cả hai vị trí extraction qua mạng đều tuân theo hành vi đã được ghi lại và kiểm thử.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- rust
- Lĩnh vực
- security
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 48/100