Rsync vulnerabilities

My read (not an expert) is that you are safe if your rsync is only via secure connections, to & from systems where untrusted parties can neither run rsync, nor play clever games with the files which rsync is accessing.

Which (in my paranoid opinion) is pretty much the only secure use case anyway, for code like rsync.

My reading is that the first two CVEs are with rsync daemon, but the others are more general - I think "rsync server" is meaning the remote rsync process that is started when you use ssh to connect to the remote. Some of them suggest the rsync client (running on your machine) can be coerced to write to unexpected locations by a malicious rsync server specifically crafted to exploit these CVEs. One suggests a malicious rsync server might be able to reconstruct the contents of arbitrary files on the client using requests sent via the rsync protocol.

I guess the main takeaway is to be careful using rsync connections to machines that you don't trust.

Every rsync operation (even locally) involves an rsync client and a separate rsync server process.

It's the same protocol and code implementing it just proxied over SSH instead of a local pipe or unix socket pair. It's a real world issue unless you trust the remote rsync process and the connection with your local user. So basically only SSH between your single-user desktop and same single-user laptop is unimpacted.

I'm running several Linux distros and package updates to rsync version 3.2.7 have showed up on all of them already. I can't comment on openrsync.

Given the more permissive license openrsync would be in a pickle if they stole the vulnerable GPL code and claimed to redistribute it under BSD license instead of reimplementing the protocol.

Debian issued a security update too:

  rsync (3.2.7-1+deb12u1) bookworm-security; urgency=high

openrsync is a neat story, it was made because they wanted to use rsync in the rpki system, but the standards body balked, saying they should not be using something where the standard was the implementation, so the openbsd folk(specifically Kristaps Dzonsons) stepped up and made a second rsync implementation so that the standards body could accept the protocol.

http://man.openbsd.org/rpki-client

It applies to only to rsync and to not the (Open)BSD rewrite openrsync. openrsync intentionally doesn't reimplement all features so it's not always a drop in replacement.

Fix was merged an hour ago, roughly an hour after you made this comment (at which time they were still working on it)

Openbsd do unsurprisingly have higher standards for code quality.

For a concrete example: https://www.gentoo.org/support/rsync-mirrors/

Gentoo's package manager most typically updates over rsync.