Path Traversal in Charm Wish SCP Middleware - Directory Escape via Unvalidated Symbolic Resolution
The SCP middleware in charm.land/wish fails to validate resolved paths remain within configured root directories, allowing unauthenticated clients to read/write arbitrary files. This PoC demonstrates a fundamental flaw in path sanitization logic affecting all current versions.
CVE References
Affected
Vulnerability Description
This is a canonical path traversal vulnerability (CWE-22) in the SCP protocol handler. The prefixed() method attempts sandbox enforcement through string prefix matching against a root directory, but the logic is fundamentally flawed. The filepath.Clean() function resolves ../ sequences but does not restrict the result to the root scope. When filepath.Join(h.root, path) is called with a path like ../../etc/passwd, the directory traversal succeeds because the joined result escapes upward from the root. The vulnerability permits both arbitrary file read (via scp -f) and arbitrary file write/directory creation (via scp -t), with no authentication required at the file operation layer.
PoC Significance
This disclosure proves the vulnerability is reliable and exploitable without special preconditions—any SCP client implementation can craft RFC 4251-compliant protocol messages with traversal sequences in filenames. The regex patterns reNewFile and reNewFolder accept any string, providing no secondary validation. The PoC's significance lies in demonstrating that the sandbox bypass is trivial to execute: an attacker simply needs to send C0644 1024 ../../sensitive/file over the SCP wire to write outside the intended root. This affects all active versions in the main branch and likely v1 releases with identical code patterns.
Detection Guidance
Log Indicators:
- SCP protocol messages (captured via tcpdump/network inspection) containing
../or..\in filename fields - File operations attempting paths outside configured root (audit logs should show resolved paths like
/etc/passwdwhen root is/var/scp) - Unexpected file modifications in parent directories of the SCP root
- Connection logs showing SCP sessions followed by file access outside intended scope
Detection Rules:
- Monitor for SCP commands with relative path components:
grep -E 'C[0-9]{4}.*\.\./' /var/log/auth.log(if SCP logging enabled) - Network IDS signatures: match SCP protocol
^[CD]messages containing../or URL-encoded equivalents - File integrity monitoring: flag unexpected changes to critical system paths when SCP service is running
Mitigation Steps
- Immediate: Disable the SCP module or restrict SCP access to trusted networks only via firewall rules
- Patching: Apply the upstream fix when available—expect the corrected
prefixed()logic to usefilepath.Rel()and validate the result begins with.or a filename (no parent traversal), or usefilepath.EvalSymlinks()with boundary checking - Workaround: Run the Wish service in a chroot jail or container with a read-only root filesystem and minimal mounted volumes
- Configuration: Ensure the SCP root directory is on a separate partition with restricted permissions; use read-only mounts where possible
- Validation: Any patched version should include unit tests verifying
../,..\, symbolic links, and URL-encoded traversal sequences are rejected
Risk Assessment
Likelihood of Exploitation: Very High. Path traversal in SCP is a well-known attack class, and this implementation flaw is trivial to exploit. Automated scanning tools will detect exposed SCP services, and proof-of-concept exploits will likely surface rapidly once public awareness grows.
Threat Actor Interest: Critical infrastructure and managed service providers using Charm Wish for secure file transfer are high-value targets. Lateral movement via arbitrary file write (e.g., injecting SSH keys or modifying configuration files) makes this attractive for post-compromise persistence. The lack of authentication at the file operation layer eliminates the attacker prerequisite burden.
Sources