Bug 675036 (CVE-2011-1097)
| Summary: | CVE-2011-1097 rsync: Incremental file-list corruption due to temporary file_extra_cnt increments | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Matt McCutchen <matt> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bressers, jlieskov, mvadkert, security-response-team, ssorce, vdanen, vkrizan, wayned |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-07-29 13:44:11 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: | 684932, 684933, 688923 | ||
| Bug Blocks: | |||
|
Description
Matt McCutchen
2011-02-04 00:21:09 UTC
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 |