A path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive
option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive
option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the clients intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ‘…/…//’ (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
Name | Vendor | Start Version | End Version |
---|---|---|---|
Rsync | Samba | * | 3.3.0 (including) |
Red Hat Enterprise Linux 8 | RedHat | rsync-0:3.1.3-21.el8_10 | * |
Red Hat Enterprise Linux 9 | RedHat | rsync-0:3.2.5-3.el9 | * |
Red Hat Enterprise Linux 9 | RedHat | rsync-0:3.2.5-3.el9 | * |
Red Hat Discovery 1.14 | RedHat | registry.redhat.io/discovery/discovery-ui-rhel9:sha256:492e412759cf0eedfa5b557f7b0865f8864f84d0ed75e11dc8d7a840837d9644 | * |
Rsync | Ubuntu | devel | * |
Rsync | Ubuntu | esm-infra-legacy/trusty | * |
Rsync | Ubuntu | esm-infra/bionic | * |
Rsync | Ubuntu | esm-infra/xenial | * |
Rsync | Ubuntu | focal | * |
Rsync | Ubuntu | jammy | * |
Rsync | Ubuntu | noble | * |
Rsync | Ubuntu | oracular | * |
Rsync | Ubuntu | trusty/esm | * |
Rsync | Ubuntu | upstream | * |
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The ‘…/…//’ manipulation is useful for bypassing some path traversal protection schemes. If “../” is filtered in a sequential fashion, as done by some regular expression engines, then “…/…//” can collapse into the “../” unsafe value (CWE-182). Removing the first “../” yields “….//”; the second removal yields “../”. Depending on the algorithm, the product could be susceptible to CWE-34 but not CWE-35, or vice versa.