rclone archive/zip: Zip Slip via unsanitized zip entry names lets a malicious archive escape its own namespace

rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.72.0 until 1.75.1, the archive ZIP backend method (*Fs).readZip in backend/archive/zip/zip.go accepts archive/zip.File.Name values from an untrusted central directory and exposes cleaned entry names without ensuring that they remain inside the archive namespace. Entries such as ../../etc/cron.d/evil can survive path.Clean and become Object.Remote() values that fs/sync and fs/operations use as destination-relative paths, allowing rclone copy or sync to write outside the selected destination on backends that do not independently confine the path. The non-empty root check also used strings.HasPrefix without a path boundary, so root foo could incorrectly include sibling foobar entries. This issue is fixed in version 1.75.1.

rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.72.0 until 1.75.1, the archive ZIP backend method (*Fs).readZip in backend/archive/zip/zip.go accepts archive/zip.File.Name values from an untrusted central directory and exposes cleaned entry names without ensuring that they remain inside the archive namespace. Entries such as ../../etc/cron.d/evil can survive path.Clean and become Object.Remote() values that fs/sync and fs/operations use as destination-relative paths, allowing rclone copy or sync to write outside the selected destination on backends that do not independently confine the path. The non-empty root check also used strings.HasPrefix without a path boundary, so root foo could incorrectly include sibling foobar entries. This issue is fixed in version 1.75.1.

rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.72.0 until 1.75.1, the archive ZIP backend method (*Fs).readZip in backend/archive/zip/zip.go accepts archive/zip.File.Name values from an untrusted central directory and exposes cleaned entry names without ensuring that they remain inside the archive namespace. Entries such as ../../etc/cron.d/evil can survive path.Clean and become Object.Remote() values that fs/sync and fs/operations use as destination-relative paths, allowing rclone copy or sync to write outside the selected destination on backends that do not independently confine the path. The non-empty root check also used strings.HasPrefix without a path boundary, so root foo could incorrectly include sibling foobar entries. This issue is fixed in version 1.75.1.

### Summary `backend/archive` mounts a zip file as a browsable, syncable rclone `Fs` (e.g. `rclone lsf :zip:downloaded.zip` or `rclone copy :zip:downloaded.zip dest:`). Go's `archive/zip` package does not sanitize `file.Name` - it is taken verbatim from the untrusted zip's central directory. `readZip()` in `backend/archive/zip/zip.go` applies `path.Clean` to the entry name, but this alone cannot fully neutralize a name with more `..` components than real segments preceding them (e.g. `"../../etc/cron.d/evil"` stays exactly as-is after cleaning). When the archive is mounted with an empty root (the common case), there was no check at all that the resulting name stayed inside the archive's own namespace, so it was stored verbatim and returned unchanged by `Object.Remote()`. `fs/sync`/`fs/operations` use `srcObj.Remote()` directly as the destination-relative path when copying between filesystems, so a maliciously crafted zip file can cause `rclone copy`/`sync` to attempt writes outside the intended destination directory on whatever backend it targets - this is the well-known "Zip Slip" vulnerability class (https://security.snyk.io/research/zip-slip-vulnerability) applied to rclone's own zip-mounting backend. It is distinct from `cmd/archive/extract`, which already validates via its own `destPath()` choke point and is not affected. ### Details Vulnerable code (before fix), `backend/archive/zip/zip.go`, `(*Fs).readZip`: ```go for _, file := range zr.File { remote := strings.Trim(path.Clean(file.Name), "/") if remote == "." { remote = "" } remote = path.Join(f.prefix, remote) if f.root != "" { // Ignore all files outside the root if !strings.HasPrefix(remote, f.root) { continue } ... } ... o := &Object{f: f, remote: remote, ...} dt.Add(o) } ``` The escape check only ran when `f.root != ""`, and even then used a bare `strings.HasPrefix` with no boundary check (so `f.root="foo"` incorrectly also matched a sibling entry `"foobar"`). ### PoC Built a zip in memory with Go's real `archive/zip` writer (entry name `"../../etc/cron.d/evil"`, not sanitized by the writer either), wrote it to disk, and mounted it via the actual production constructor `zip.New(ctx, localFs, "evil.zip", "", "")`: ``` zip entry Name="../../etc/cron.d/evil" -> Object.Remote()="../../etc/cron.d/evil" ``` Fully outside the archive's own namespace - confirmed via a regression test that mounts the malicious zip through the real `local` backend and inspects the resulting Fs's internal dirtree and every Object's `Remote()`. ### Impact A user who runs `rclone copy`/`sync`/`mount` against an untrusted zip file (downloaded, e-mailed, etc.) can have files written outside the intended destination directory on the destination backend, depending on that backend's own confinement. No server compromise or custom remote configuration is required from the attacker - only a crafted zip file and a normal `rclone copy`/`sync` invocation by the victim. ### Fix Skip any zip entry whose cleaned+prefixed name still escapes the archive's own namespace, rather than exposing it. Also tightened the pre-existing root filter's weak prefix check.

rclone archive/zip: Zip Slip via unsanitized zip entry names lets a malicious archive escape its own namespace in github.com/rclone/rclone