rsync - Jul 2022 - [Bug 15122] New: Potential vulnerability: rsync creates files outside the target directory

https://bugzilla.samba.org/show_bug.cgi?id=15122

            Bug ID: 15122
           Summary: Potential vulnerability: rsync creates files outside
                    the target directory
           Product: rsync
           Version: 3.2.0
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayne at opencoder.net
          Reporter: azb254 at psu.edu
        QA Contact: rsync-qa at samba.org
  Target Milestone: ---

Created attachment 17422
  --> https://bugzilla.samba.org/attachment.cgi?id=17422&action=edit
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=15122

--- Comment #1 from Wayne Davison <wayne at opencoder.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=15122

--- Comment #2 from Wayne Davison <wayne at opencoder.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=15122

--- Comment #3 from Aditya Basu <azb254 at psu.edu> ---
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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.