4 ms·

Do I read correctly that this is related to "rsync daemon" (rsyncd), and therefore has minimal impact on people who just use rsync over ssh?

throwaway984393 2y ago
[dead]
bell-cot 2y ago
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.
- kees99 2y ago
  > you are safe if your rsync is only via secure connections Not quite. If server has "command=rsync ..." in ~/.ssh/authorized_keys file, for some ssh key (to allow rsync access, but deny shell access), this vulnerability will allow attacker in possession of that ssh key to go around that restriction, and get shell nonetheless.
  - nrdvana 2y ago
    He said where untrusted parties aren't able to run rsync. If I was running an rsync daemon facing the public, it would be in a chroot with dropped privileges.
mhw 2y ago
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.
formerly_proven 2y ago
Every rsync operation (even locally) involves an rsync client and a separate rsync server process.
crest 2y ago
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.
aaron695 2y ago
[dead]

throwaway984393 2y ago

[dead]

bell-cot 2y ago

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.

kees99 2y ago
> you are safe if your rsync is only via secure connections Not quite. If server has "command=rsync ..." in ~/.ssh/authorized_keys file, for some ssh key (to allow rsync access, but deny shell access), this vulnerability will allow attacker in possession of that ssh key to go around that restriction, and get shell nonetheless.
- nrdvana 2y ago
  He said where untrusted parties aren't able to run rsync. If I was running an rsync daemon facing the public, it would be in a chroot with dropped privileges.

mhw 2y ago

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.

formerly_proven 2y ago

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

crest 2y ago

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.

aaron695 2y ago

[dead]