fix(security): cap bsdtar extraction size to prevent decompression bomb DoS [DEVA11Y-484]

[maunilm]

Summary

• CWE-400 (Uncontrolled Resource Consumption) — OWASP A05. bsdtar was invoked with no decompressed-size or entry-count limit, so an attacker who can influence the download URL (the HTTPS-only --download-url / BROWSERSTACK_A11Y_CLI_DOWNLOAD_URL override, or TLS interception of the default endpoint) could serve a decompression bomb that exhausts developer/CI disk space.
• Fix covers all four affected surfaces: the Swift SPM plugin and the bash, zsh, and fish wrappers (the ticket only flagged scripts/bash/cli.sh; zsh/fish were byte-identical).
• Ships with a real-process regression suite (no mocks) — see below.

What changed

Plugins/BrowserStackAccessibilityLint.swift

• curl --max-filesize (100 MB) caps the compressed download.
• A background watchdog terminates bsdtar once the decompressed footprint exceeds 200 MB or 10,000 entries. A cap on the curl→bsdtar pipe would only bound compressed bytes — useless against a bomb — so the guard measures what lands on disk. The entry ceiling closes the "millions of tiny files" variant that stays small on disk.
• A post-extraction footprint check makes detection deterministic on fast disks: a bomb that finishes decompressing within a single 200 ms poll interval is caught and cleaned up rather than slipping past the live watchdog.
• Applied to both the remote and local extraction paths; on rejection the partial directory is removed and the run aborts.
• locateExecutable also bounds enumeration at 10,000 entries (secondary defense).

scripts/{bash,zsh,fish}/cli.sh

• curl --max-filesize caps the compressed download.
• bsdtar … -O output is piped through head -c (200 MB) with set -o pipefail; an oversized archive aborts (and deletes the partial binary) instead of filling the disk. head -c is a hard synchronous cap, so the shell path has no poll-gap and needs no entry check in -O mode (nothing is written per-entry).

Tests (scripts/test/, run via run_tests.sh)

Real curl/bsdtar/head and the real Swift watchdog against crafted archives on a local server — no mocked unit tests.

• Shell: the REAL download_binary is extracted verbatim from all three wrappers and run against the server; only the hardcoded URL is redirected (via a curl shim), so the security pipeline runs unmodified.
• Swift: SwiftPM command plugins can't be imported by a test target, so a mirror harness compiles the guard block verbatim and drives real processes; check_drift.sh fails CI if the mirror diverges from the plugin.
• Scenarios: legit (downloads → extracts → runs), 400 MB decompression bomb, 20k-entry bomb, oversized (>100 MB) download, corrupt archive, multi-file archive, missing URL/network failure.
• Fixtures are bounded (≤400 MB, gitignored) and bomb tests use a small cap, so a regressed guard can never exhaust the disk. 53/53 assertions green locally; full run ~9 s; disk usage flat before/after.
• CI: .github/workflows/extraction-guard-tests.yml runs the suite on macOS for PRs touching the download/extract path.

No breaking change to legitimate downloads

The real CLI artifact (macos arm64) is ~34 MB compressed / ~64 MB decompressed, so the 100 MB / 200 MB caps leave ~3× headroom. Verified end-to-end: the real production artifact passes through the new extraction path, extracts to a valid Mach-O, and runs.

Note on scope vs. the ticket

The ticket's primary vector (MitM on a plaintext download) is already closed by DEVA11Y-479 (override restricted to HTTPS; default URL is HTTPS). This PR is defense-in-depth against the remaining vectors: an attacker-controlled HTTPS override endpoint, or TLS interception.

Jira

DEVA11Y-484 · umbrella APPSEC-415

🤖 Generated with Claude Code