The recv_files function in receiver.c in the daemon in rsync 3.1.2, and 3.1.3-development before 2017-11-03, proceeds with certain file metadata updates before checking for a filename in the daemon_filter_list data structure, which allows remote attackers to bypass intended access restrictions. Upstream patch: https://git.samba.org/?p=rsync.git;a=commit;h=3e06d40029cfdce9d0f73d87cfd4edaf54be9c51
Created rsync tracking bugs for this issue: Affects: fedora-all [bug 1511414]
Statement: Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Reanalyzed. I couldn't even reproduce the flaw, because there are other checks in place that seem to prevent the application from reaching the "vulnerable" code. Upstream maintainer didn't reply to my questions over email about this flaw. What I found is that function get_local_name(), called before recv_files(), does check that when the destination path on the server is specified it is not in the excluded list. When the destination path is not speficied (e.g. rsync -avzh ./dst/ rsync://XXXXX/ftp), function recv_generator() does check that the resulting path is not excluded. So it seems the check in recv_files() is just for double safety (aka hardening) and this seems to be somehow confirmed by the fact the error message is "attempt to hack rsync failed", different from the other user-facing errors like "ERROR: daemon refused to receive file "testfile"". That said, this doesn't seem to be Critical (nor a flaw at all actually), but just a security hardening. Also, even assuming that somehow the code is reachable, only some metadata can be changed (e.g. number of transferred files, number of created files, total transferred size, etc.).