Skip to content

GHSA-4mfr-8jrv-49x4

CVE Information

rsync followed attacker-planted symlinks in operator-supplied input file paths: --filter merge files and per-directory merge files (incl. -C .cvsignore), --files-from / --include-from / --exclude-from, and the client --password-file / daemon secrets file. A local user who controls a path component plants a symlink; a privileged rsync then reads an arbitrary file either as filter rules (silent transfer shaping, and disclosure under -v/-i/--debug) or, for the password/secrets case, reads a victim file and sends its contents as the daemon authentication response (credential disclosure).

Additional variant (same class — a symlink in an operator/peer-supplied input path reads outside the intended tree): a daemon --files-from=:<list> transfer could still read a file outside the served module even after the general input-path hardening: the peer-supplied files-from open was not confined to the module root, so a receiver-euid-owned symlink planted under a backup directory redirected the open to an arbitrary out-of-module file (the same link-following read on the --files-from input, in the daemon module-confinement path).

Fix: resolve operator-supplied paths component-by-component with openat(O_PATH|O_NOFOLLOW), allowing a symlink component only when owned by uid 0 or the effective uid; and confine the daemon files-from open to the served module root.

Tests: excludefrom-symlink, filter-merge-symlink, password-file-symlink, files-from-leak.

Credit: maintainer audit; Omar Elsayed (seks99x); Andreas Gabriel Berbescu (4drez); Ivan Redondo (S0S4)— daemon --files-from module-confinement variant.

Affected: rsync 3.4.3 and earlier; fixed in 3.5.0. (Precise introduced-in ranges being finalised.)