Bug 1522874 (CVE-2017-17433)

Summary:	CVE-2017-17433 rsync: recv_files function metadata handling allows for access restriction bypass
Product:	[Other] Security Response	Reporter:	Andrej Nemec <anemec>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	code, hobbes1069, luhliari, mruprich, slukasik, ssorce, yozone
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-19 16:27:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1511414
Bug Blocks:	1515738

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:

https://git.samba.org/?p=rsync.git;a=commit;h=3e06d40029cfdce9d0f73d87cfd4edaf54be9c51

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

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

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

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