https://kb.cert.org/vuls/id/952657: """ CVE-2024-12084 A heap-buffer-overflow vulnerability in the Rsync daemon results in improper handling of attacker-controlled checksum lengths (s2length). When the MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out-of-bounds in the sum2 buffer. CVE-2024-12085 When Rsync compares file checksums, a vulnerability in the Rsync daemon can be triggered. An attacker could manipulate the checksum length (s2length) to force a comparison between the checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. CVE-2024-12086 A vulnerability in the Rsync daemon could cause a server to leak the contents of arbitrary files from clients’ machines. This happens when files are copied from client to server. During the process, a malicious Rsync server can generate invalid communication tokens and checksums from data the attacker compares. The comparison will trigger the client to ask the server to resend data, which the server can use to guess a checksum. The server could then reprocess data, byte to byte, to determine the contents of the target file. CVE-2024-12087 A path traversal vulnerability in the Rsync daemon affects the --inc-recursive option, a default-enabled option for many flags that can be enabled by the server even if not explicitly enabled by the client. When using this option, a lack of proper symlink verification coupled with de-duplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could remotely trigger this activity by exploiting symbolic links named after valid client directories/paths. CVE-2024-12088 A --safe-links option vulnerability results in Rsync failing to properly verify whether the symbolic link destination contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary files being written outside of the desired directory. CVE-2024-12747 Rsync is vulnerable to a symbolic-link race condition, which may lead to privilege escalation. A user could gain access to privileged files on affected servers. """ The new release isn't out yet, it should be in a few hours, apparently.
Out now: https://download.samba.org/pub/rsync/NEWS#3.4.0
Tin foil libxz hat time... The new release claims to be made by Andrew Tridgell, original rsync author, but he hasn't done a release of rsync since 2002. It's signed by a key not yet in a sec-keys/ package: pub rsa4096 2017-09-23 [SC] 9FEF112DCE19A0DC7E882CB81BB24997A8535F6F uid [ unknown] Andrew Tridgell <andrew@tridgell.net> sig 3 1BB24997A8535F6F 2017-09-23 [self-signature] sub rsa4096 2017-09-23 [E] sig 1BB24997A8535F6F 2017-09-23 [self-signature] That's not the historical address or key he's typically used to interact with Samba and other projects (tridge@samba.org and the like), although the domain's been registered since 2001. Neither that address nor that PGP key are mentioned at https://www.samba.org/~tridge/ (It does link to http://blog.tridgell.net/ which now 403's.) That key is in the public keyservers, but that's no real confirmation, now that they strip off signatures, etc. His mirror of the rsync repo, https://github.com/tridge/rsync, hasn't synced in about 9 months. No public key has been attached to that account at https://github.com/tridge.gpg The commit that updated Changelog was made by tridge's github account, although it credits Wayne Davison (previous/recent maintainer): https://github.com/RsyncProject/rsync/commit/e3ee0e7319eb4250ddb76b716510fd20441da329 It's probably nothing, but the combination of "remote unauth RCE" and "sudden change of maintainer signing key" is a perfect setup if you _had_ broken into tridgell.net and had him tied up in your basement. Can anyone confirm w/Tridgell out-of-band, confirm they had that PGP key previously and it didn't just spring into existence, etc.?
For what it's worth, this being the first release since 2002 that Tridgell has signed is expected. From the previous release announcement (https://lists.samba.org/archive/rsync-announce/2024/000119.html): > The github repos have moved to a new RsyncProject organization. Because > various life events have been monopolizing my time, I reached out to Tridge > (the original author) and he has graciously agreed to get back into rsync > work, along with Paul Mackerras, who was also an early contributor to > rsync. This new team will be working mainly on maintenance tasks, and not > so much on new features. If you want to get involved, feel free to reach > out on the new discord RsyncProject channels.
(In reply to snow flurry from comment #3) > For what it's worth, this being the first release since 2002 that Tridgell > has signed is expected. From the previous release announcement > (https://lists.samba.org/archive/rsync-announce/2024/000119.html): ... Thanks for finding that, it is a bit reassuring. Also the andrew@tridgill.net account has been making commits to the RsyncProject-owned repo since about April of last year - although those commits are not signed. That PGP key is also available on Ubuntu keyservers with a few other parties' signatures attached - although those signatures were added _today_: https://keyserver.ubuntu.com/pks/lookup?search=andrew%40tridgell.net&fingerprint=on&op=index ...Including a signature by the former active maintainer. If an intruder were able to fabricate signatures by that key, they could presumably have just made a malicious release using it and there'd be nothing to stand out at all.
Just getting up now but https://github.com/gentoo/gentoo/pull/40139#discussion_r1916293395 (let's not bump yet until had time to investigate)
Note that there seems to be a regression around hard link handling :( https://github.com/RsyncProject/rsync/issues/702 Maybe backporting the security fixes only is better for now.
I'm working on backports now.
There's several regressions. * https://github.com/RsyncProject/rsync/issues/701 (fix: https://github.com/RsyncProject/rsync/pull/707) * https://github.com/RsyncProject/rsync/issues/697 and https://github.com/RsyncProject/rsync/issues/702 (fix: https://github.com/RsyncProject/rsync/pull/705) * https://github.com/RsyncProject/rsync/issues/704 (fix: https://github.com/RsyncProject/rsync/pull/706) Unfortunately, at least #2 is part of the CVE fixes.
(In reply to Sam James from comment #8) > There's several regressions. > > * https://github.com/RsyncProject/rsync/issues/701 (fix: > https://github.com/RsyncProject/rsync/pull/707) > * https://github.com/RsyncProject/rsync/issues/697 and > https://github.com/RsyncProject/rsync/issues/702 (fix: > https://github.com/RsyncProject/rsync/pull/705) > * https://github.com/RsyncProject/rsync/issues/704 (fix: > https://github.com/RsyncProject/rsync/pull/706) > * https://github.com/RsyncProject/rsync/issues/699
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f7f0c1ba3889f8fe443710f3ff9781df2a371863 commit f7f0c1ba3889f8fe443710f3ff9781df2a371863 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-15 16:11:31 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-15 16:14:56 +0000 net-misc/rsync: backport CVe fixes to 3.3.0-r2 Not bumping to 3.4.0 yet as there's a bunch of regressions and seems safer to just do these patches, albeit there's some fixups needed for these too (see CVE-*-*-2.patch files). These backports come from RH shared on the VINCE case. I'll look at doing 3.2.7 next, but may not go ahead with that. Bug: https://bugs.gentoo.org/948106 Signed-off-by: Sam James <sam@gentoo.org> .../files/3.3.0/rsync-3.3.0-CVE-2024-12084.patch | 132 +++++++++++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12085.patch | 17 ++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12086-1.patch | 200 ++++++++++++++++++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12086-2.patch | 26 +++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12087-1.patch | 39 ++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12087-2.patch | 36 ++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12088.patch | 60 ++++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12747-1.patch | 166 ++++++++++++++++ .../files/3.3.0/rsync-3.3.0-CVE-2024-12747-2.patch | 34 ++++ net-misc/rsync/rsync-3.3.0-r2.ebuild | 209 +++++++++++++++++++++ 10 files changed, 919 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=889122c49e5c31f1eef3898e4cc046b7dc7e71e3 commit 889122c49e5c31f1eef3898e4cc046b7dc7e71e3 Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2025-01-15 17:18:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-15 17:18:39 +0000 [ GLSA 202501-01 ] rsync: Multiple Vulnerabilities Bug: https://bugs.gentoo.org/948106 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> glsa-202501-01.xml | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
Another regression: https://github.com/RsyncProject/rsync/issues/715