🔍 Issue Description
mofa plugin install extracts .tar.gz archives using ar::Archive::unpack(dest_dir). This broad extraction path can allow archive entries to target paths outside the plugin directory (classic archive path traversal / Zip-Slip style risk), depending on entry metadata and runtime behavior.
📌 Issue Type
📝 Description
What is happening?
The plugin installer URL flow calls extract_tar_gz() and delegates extraction to �rchive.unpack(dest_dir). That API extracts all entries directly and does not give us explicit per-entry allow/deny control in our installer logic.
What should happen instead?
Tar extraction should be entry-by-entry with destination confinement checks, rejecting any entry that can escape dest_dir.
Why is this needed?
Plugin archives are external inputs in a supply-chain-sensitive code path. A malicious archive could attempt to write outside the plugin install location (e.g., overwrite user files or runtime config), which is high-impact.
Reproduction / semantic mismatch
- Craft a tar.gz archive containing traversal-style entries such as ../escape.txt (or equivalent escape metadata).
- Run mofa plugin install https://example.com/malicious.tar.gz.
- Current implementation uses bulk unpack, instead of explicit confined extraction logic in the installer.
Impact
- Security boundary violation in plugin install path.
- Potential arbitrary file write outside plugin directory.
- Affects users installing plugins from remote archives.
🎯 Proposed Solution (Optional but Encouraged)
- Replace �rchive.unpack(dest_dir) with per-entry extraction.
- Use entry.unpack_in(dest_dir) and reject entries that return alse (escape attempt).
- Surface clear error context with the offending entry path.
- Add regression test that builds a traversal-style tar entry and asserts extraction is rejected.
Relevant module:
- crates/mofa-cli/src/commands/plugin/install.rs
📎 Additional Context
Duplicate checks done before filing:
- Open issues searched: plugin install archive path traversal zip slip (none matching)
- Open PRs searched: mofa-cli plugin install (none addressing tar traversal hardening)
- Merged PRs searched: plugin install archive zip tar extract (none covering this fix)
🙋 Claiming This Issue
🔔 Important
I’d like to work on this.
🔍 Issue Description
mofa plugin install extracts .tar.gz archives using ar::Archive::unpack(dest_dir). This broad extraction path can allow archive entries to target paths outside the plugin directory (classic archive path traversal / Zip-Slip style risk), depending on entry metadata and runtime behavior.
📌 Issue Type
📝 Description
What is happening?
The plugin installer URL flow calls extract_tar_gz() and delegates extraction to �rchive.unpack(dest_dir). That API extracts all entries directly and does not give us explicit per-entry allow/deny control in our installer logic.
What should happen instead?
Tar extraction should be entry-by-entry with destination confinement checks, rejecting any entry that can escape dest_dir.
Why is this needed?
Plugin archives are external inputs in a supply-chain-sensitive code path. A malicious archive could attempt to write outside the plugin install location (e.g., overwrite user files or runtime config), which is high-impact.
Reproduction / semantic mismatch
Impact
🎯 Proposed Solution (Optional but Encouraged)
Relevant module:
📎 Additional Context
Duplicate checks done before filing:
🙋 Claiming This Issue
🔔 Important
I’d like to work on this.