3 ms·

> but rsync itself has massive risks Err, what risks? If you run a server? Sure, but as a replacement for scp, where it's assumed you have an account on the

> but rsync itself has massive risks Err, what risks? If you run a server? Sure, but as a replacement for scp, where it's assumed you have an account on the remote system, an rsync server is not the equivalent solution, running rsync across an ssh connection is. > Rsync over SSH is less risky but not risk free to either side. What is sent and what is asked for do not have to align well) Glossing over that no system is "risk free", can you explain in a bit more detail here, or reference what you wrote up or some other thing? That's the kind of thing I would really want to know about, and an unsubstantiated throw-away aside does not do justice to the problem if accurate.

ggm 6y ago
https://datatracker.ietf.org/meeting/89/materials/slides-89-sidr-6 https://datatracker.ietf.org/meeting/89/materials/slides-89-...
- ggm 6y ago
  The principle point is that if the server is compromised, the ssh tunnel just becomes a mechanism to propagate things. If you say --size-only or --no-delete or whatever, it doesn't acually constrain what happens over the rsync protocol. It just says what you want the other side to know: if the other side is a bad actor, it can send you whatever it likes, and that can include filepaths outside the local constraint you think you scoped it to (the target can be ../../.. specified)
  - kbenson 6y ago
    Yeah, I was just reading, thanks for sending the link. What I'm at so far, which is that you were able to successfully get a client to write outside of it's expected root location using a 119 line python script as the server, is pretty problematic in itself if not yet fixed/mitigated in some way. :/ Did you event submit these finding as a bug? I would be interested in tracking this if it was accepted. It looks like this note from 3.1.2's release[1] is it, but I'm not sure: File-list validation in 3.1.2 December 21st, 2015 If you're using a version of rsync older than 3.1.2 as a client and receiving files from an rsync server that you might not fully trust, this version adds extra checking to the file list to prevent the sender from tweaking the paths and/or the transfer requests in a way that could cause a file to be received outside the transfer destination. 1: https://rsync.samba.org/security.html#s3_1_3 https://rsync.samba.org/security.html#s3_1_3

ggm 6y ago

https://datatracker.ietf.org/meeting/89/materials/slides-89-sidr-6 https://datatracker.ietf.org/meeting/89/materials/slides-89-...

ggm 6y ago
The principle point is that if the server is compromised, the ssh tunnel just becomes a mechanism to propagate things. If you say --size-only or --no-delete or whatever, it doesn't acually constrain what happens over the rsync protocol. It just says what you want the other side to know: if the other side is a bad actor, it can send you whatever it likes, and that can include filepaths outside the local constraint you think you scoped it to (the target can be ../../.. specified)
- kbenson 6y ago
  Yeah, I was just reading, thanks for sending the link. What I'm at so far, which is that you were able to successfully get a client to write outside of it's expected root location using a 119 line python script as the server, is pretty problematic in itself if not yet fixed/mitigated in some way. :/ Did you event submit these finding as a bug? I would be interested in tracking this if it was accepted. It looks like this note from 3.1.2's release[1] is it, but I'm not sure: File-list validation in 3.1.2 December 21st, 2015 If you're using a version of rsync older than 3.1.2 as a client and receiving files from an rsync server that you might not fully trust, this version adds extra checking to the file list to prevent the sender from tweaking the paths and/or the transfer requests in a way that could cause a file to be received outside the transfer destination. 1: https://rsync.samba.org/security.html#s3_1_3 https://rsync.samba.org/security.html#s3_1_3