Bug 1522874 (CVE-2017-17433) - CVE-2017-17433 rsync: recv_files function metadata handling allows for access restriction bypass
Summary: CVE-2017-17433 rsync: recv_files function metadata handling allows for access...
Alias: CVE-2017-17433
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1511414
Blocks: 1515738
TreeView+ depends on / blocked
Reported: 2017-12-06 16:05 UTC by Andrej Nemec
Modified: 2021-03-11 16:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-19 16:27:13 UTC

Attachments (Terms of Use)

Description Andrej Nemec 2017-12-06 16:05:27 UTC
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:


Comment 1 Andrej Nemec 2017-12-06 16:12:45 UTC
Created rsync tracking bugs for this issue:

Affects: fedora-all [bug 1511414]

Comment 2 Raphael Sanchez Prudencio 2017-12-19 16:27:23 UTC

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/.

Comment 4 Riccardo Schirone 2019-04-30 13:59:43 UTC

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.).

Note You need to log in before you can comment on or make changes to this bug.