GHSA-3c3x-ww2w-5r5p
CVE Information
rsync-ssl wraps the rsync daemon protocol in TLS using an external helper. A user who invokes it is entitled to assume the server certificate is authenticated; on two of the three backends it was not.
- stunnel (AFFECTED, through 3.4.4). With no CA configured the generated stunnel configuration performed no certificate verification at all; with a CA configured it verified the chain but did NOT bind the certificate to the requested hostname. Both forms are demonstrated by the two stunnel tests.
- openssl (AFFECTED, 3.2.0 through 3.2.3). The helper invocation lacked -verify_hostname, so the chain was checked but the hostname was not. Matt McCutchen added it in 2020, released in 3.2.4, so releases from 3.2.4 on are not affected; the openssl test covers the new opt-out rather than a live defect.
- gnutls (NOT demonstrated vulnerable). gnutls-cli documents CA verification as enabled by default and uses the command-line hostname for certificate verification. 3.5.0 nonetheless refuses to rely on an implicit system trust store, because that behaviour is not dependable across helper versions -- treat that as hardening, not a fixed defect. There is no GnuTLS regression proving a vulnerable helper version. The refusal is Greg Kroah-Hartman's; he is credited for that hardening, not as the reporter of a demonstrated vulnerability.
Where affected, a machine-in-the-middle defeats the confidentiality and integrity the user believes rsync-ssl provides. Being a shipped wrapper script rather than the daemon does not remove the TLS authentication boundary.
Affected: per backend, see below -- stunnel through 3.4.4; openssl 3.2.0 through 3.2.3
Fixed in: 3.5.0 (rsync-ssl)
Reporter: per backend -- the stunnel defect is maintainer audit; the openssl hostname defect was found and fixed in 2020 by Matt McCutchen; the conservative GnuTLS refusal is Greg Kroah-Hartman's
Tests: rsync-ssl-stunnel-ca-required, rsync-ssl-stunnel-hostname-check, rsync-ssl-openssl-hostname-check