Created attachment 17422 [details] POC of vulnerability The problem arises when trying to copy from a "case-sensitive" source to a "case-insensitive" target. The copy involves directories, files, and symbolic links (to directories). A maliciously crafted source directory can result in rsync following symbolic links and writing data outside the target directory. For a concrete example, consider the following source directory structure: SRC/ topdir/ secret (symlink to /tmp) TOPDIR/ secret/ config (file) We use rsync to recursively copy from SRC/ to TARGET/. Command: "rsync -a SRC/ TARGET/" Additionally, TARGET/ is on case-insensitive filesystem. Problem: During the copy, rsync creates the TOPDIR/secret/config (file) by following the symbolic link "topdir/secret". Hence, /tmp/config is created by rsync. We found a flag called: --copy-links which makes rsync follow symlinks at source before doing the copy. However, my understanding is that rsync should not follow symbolic links at the target, esp. the symbolic links it creates. I have attached a POC script that demonstrates this behavior. I have tested it on rsync versions 3.2.3 and 3.1.3. Compiling the latest version (3.2.4) of rsync results in an error during the ./configure step. Hence, I could not test it. Running Proof of concept script: The script requires two command line arguments: - Argument 1 = any empty case-sensitive directory - Argument 2 = any empty case-insensitive directory Example of invoking script for WSL: ./rsync-poc.sh ~/src /mnt/c/Users/xyz/dst
Yes, it's always bad to copy from a case-honoring filesystem to a case-ignoring filesystem as the filenames can overlap. This is something that the user just shouldn't do, as rsync is written to handle case-honoring filesystems.
BTW, what happens in the test case you provided is that the generator creates TOPDIR and then TOPDIR/secret dirs before asking the sender to start a transfer of TOPDIR/secret/config. It then goes on to notice that topdir is present (since it uses stat) and that topdir/secret is an empty directory that is in the way of a symlink, so it replaces the dir with a symlink prior to the receiver doing its file-create work. If the topdirs had sorted in the opposite order, the symlink would have been replaced with a directory.
Apologies for the late response. It is definitely a bad idea to mix multi-case systems. However, note that even copying between case-honoring systems can have similar consequences, for ex. case-insensitive (icase) ZFS considers K (unicode kelvin sign) and k (alphabet) to be equivalent while icase ext4 does not. I agree with you analysis of the ordering. However, IMHO traversing symlinks at the target is not a wise choice. An *immediate* fix to this particular issue would be to prevent rsync for traversing symlinks at the target. However, a more *complete* fix should involve detecting collisions and stopping the copy. We're currently exploring different types of defenses for collisions. If you're interested, I will be happy to keep you in the loop. Finally, does it make sense to get a CVE number assigned?