Wayne Davison and I have identified a memory safety bug in rsync >= 3.0.0, affecting the generator process (receiving side) when incremental recursion is on, --delete is on, and --owner is off. Under these conditions, some of the generator's deletion functions temporarily increment file_extra_cnt, a global variable that governs the in-memory format of file_structs, and restore the original value on completion. The increment was intended to only affect the temporary file lists used to implement deletion, but it can also affect incremental file-list chunks that happen to be received during a call to one of these functions, which will be created in the wrong format. When the original file_extra_cnt is restored, the value originally stored in each applicable OPT_EXTRA field will show up in the next one as listed in rsync.h. Most of the fields are opaque data or are validated upon use, so their corruption leads to incorrect results but no danger to rsync itself. However, rsync uses the invariant that the F_HL_PREV field (applicable when --hard-links is on) forms a linked list of file indices consistent with the FLAG_HLINK* flags. The movement of the F_HL_GNUM values (which can be chosen arbitrarily by the sender subject to some constraints) into the F_HL_PREV field has the potential to break memory safety. Upstream fix for the 3.0.x branch (sum of three commits): http://gitweb.samba.org/?p=rsync.git;a=commitdiff;h=83b94efa6b60a3ff5eee4c5f7812c617a90a03f6;hp=c8255147b06b74dad940d32f9cef5fbe17595239 Upstream bug report (marked fixed, but a full explanation has not been posted due to the security implications): https://bugzilla.samba.org/show_bug.cgi?id=7936 I would appreciate Red Hat's help in getting a CVE and determining the severity of the issue. In my testing, I have been able to make an rsync 3.0.7 generator incur valgrind errors and then segfault (details forthcoming), but we have neither confirmed nor ruled out arbitrary code execution.
These issues affecting the _receiving_ side of rsync, not the server side? So this would happen regardless of whether this was a connection to rsyncd or rsync over ssh? If the only impact is client-side, I'm not sure this would be considered a security flaw. Can this be triggered with some setting server-side, or is it dependent upon client-side options?
(In reply to comment #1) > These issues affecting the _receiving_ side of rsync, Correct. > not the server side? Rsync daemons can have writable modules, though maybe that is not something Red Hat supports for its customers. > So > this would happen regardless of whether this was a connection to rsyncd or > rsync over ssh? Yes, as far as I know. I have only tested with a remote shell. > If the only impact is client-side, I'm not sure this would be considered a > security flaw. I think the problem may never occur on a pull because the generator's output goes directly to the console instead of being sent across the socket and triggering the select loop that also receives file-list chunks. Wayne, can you confirm this?
(In reply to comment #2) > I think the problem may never occur on a pull because the generator's output > goes directly to the console instead of being sent across the socket and > triggering the select loop that also receives file-list chunks. Wayne, can you > confirm this? Under typical circumstances, yes. However, if there is a timeout in effect and the deletions are slow, the generator could sent a keep-alive message, which could trigger the checking for incoming file-list data.
Are you saying that if client pushes to server (effectively receiving by the server), that it could cause the server to crash? Do you have something on hand that we can use to reproduce this? If the client is able to make a rsync server crash by pushing to it (whether it is using ssh or not), then we certainly need to investigate this further. Also, are you sure this only affects >= 3.0.0? Just trying to determine what products would be affected by this. Sorry for taking so long to get back to you on this. Vojtech, can you take a look at this and chime in? I'm not sure I fully understand what is going on here, and whether or not this can be used to cause a problem on the server side of things (I'm not overly interested in client-side crashes when using particular options, but if it can be used to crash an rsync server, then we need to worry about it). Thanks.
(In reply to comment #4) > Are you saying that if client pushes to server (effectively receiving by the > server), that it could cause the server to crash? Yes, though in the case of an rsync daemon, only the worker process for that connection would crash. > Do you have something on > hand that we can use to reproduce this? I just need to pack up a kit. Hopefully I will get to it tonight. > If the client is able to make a rsync > server crash by pushing to it (whether it is using ssh or not), then we > certainly need to investigate this further. I'm not worried about crashes, but about whether arbitrary code execution might be possible. > Also, are you sure this only affects >= 3.0.0? Yes. The bug is in the incremental recursion feature added in 3.0.0. > I'm not overly interested in > client-side crashes when using particular options In general I believe client security is widely underappreciated, but I think it's pretty unlikely that a user would pull from an untrusted server with -H. I never have.
(In reply to comment #5) > Yes, though in the case of an rsync daemon, only the worker process for that > connection would crash. Ahh, so it wouldn't cause the daemon itself to crash (the parent), so there is no DoS issue here then. > I just need to pack up a kit. Hopefully I will get to it tonight. That would be fantastic, thank you. > I'm not worried about crashes, but about whether arbitrary code execution might > be possible. Yes, of course, but making it crash in the first place would identify whether or not there is something that could lead to arbitrary code execution. > Yes. The bug is in the incremental recursion feature added in 3.0.0. Ok, great. Thanks for that confirmation. > > I'm not overly interested in > > client-side crashes when using particular options > > In general I believe client security is widely underappreciated, but I think > it's pretty unlikely that a user would pull from an untrusted server with -H. > I never have. If it's just a client-side _crash_, those happen all the time. I wouldn't call it security, and don't believe many others would either. Having said that, if there was something the _server_ could do to make the _client_ execute arbitrary code, then we certainly have a problem. If the client can only make itself execute arbitrary code, well, it could do that without this flaw. So on the client side of things, I don't believe security is a concern unless some options on the _server_ will make the client execute arbitrary code (and if the server can tell it what code to execute, of course).
I'm giving this CVE-2011-1097. This is one of those issues we can't prove non-exploitable. Valgrind clearly shows illegal heap writes, which is good enough for me. The issue appears to be mitigated by the fact that it's on the receiving end. You'd have to connect to a malicious rsync server, or allow anonymous rsync uploads (which has a whole heap of issues in itself). I'm going to rate it as having moderate security severity becuase of these factors.
As vendor-sec is no more, we don't have a nice way to coordinate this among vendors in a private manner. Unless there is an error with my above analysis, I propose we make this public via the oss-security mailing list.
It might be preferable to wait until rsync 3.0.8 is released with the fix. Wayne, could you move that process along? I will help test.
Right, once you guys release rsync-3.0.8, please make sure the changelog mentions the CVE id, and we'll consider it public. Thanks.
Acknowledgements: Red Hat would like to thank Wayne Davison and Matt McCutchen for reporting this issue.
FYI, I've released rsync 3.0.8.
Thank you for the notification, Wayne. Public now via rsync 3.0.8 upstream release: http://samba.anu.edu.au/ftp/rsync/src/rsync-3.0.8-NEWS - Fixed a data-corruption issue when preserving hard-links without preserving file ownership, and doing deletions either before or during the transfer (CVE-2011-1097). This fixes some assert errors in the hard-linking code, and some potential failed checksums (via -c) that should have matched.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0390 https://rhn.redhat.com/errata/RHSA-2011-0390.html