Rclone has Improper Permission and Ownership Handling on Symlink Targets with --links and --metadata
Date: 2024-11
Affected: go/github.com/rclone/rclone
Attack vector: other
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2024-52522
CWE: CWE-281
CVSS: 5.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L)

### **tl;dr:** unprivileged user creates a symlink to /etc/sudoers, /etc/shadow or similar and waits for a privileged user or process to copy/backup/mirror users data (using `--links` and `--metadata`). unprivileged user now owns /etc/sudoers. ### Summary Insecure handling of symlinks with `--links` and `--metadata` in rclone while copying to local disk allows unprivileged users to indirectly modify ownership and permissions on symlink target files when a superuser or privileged process performs a copy. This vulnerability could enable privilege escalation and unauthorized access to critical system files (e.g., /etc/shadow), compromising system integrity, confidentiality, and availability. For instance, an unprivileged user could set a symlink to a sensitive file within their home directory, waiting for an administrator or automated process (e.g., a cron job running with elevated privileges) to copy their files with rclone using the --links and --metadata options. Upon copying, rclone will incorrectly apply chown and chmod to the symlink’s target file rather than just the symlink itself, resulting in ownership and permission changes on the sensitive file. ### Who is affected If you are not using `--metadata` **and** `--links` **and** copying files **to** the local backend you are not affected by this issue. If you are using `--metadata` and `-links` and copying files to the local backend but not as a superuser, then this will manifest itself as a bug by setting incorrec


Mitigations:

Architectural layers (MAESTRO):