El 19/02/2019 a las 4:16, Russ Allbery escribió: Unfortunately, I took a closer look, and it turns out that this command was never safe. It also allows arbitrary code excution on the server side if the client can write to $HOME. This is because: --config=FILE This specifies an alternate config file than the default. This is only relevant when --daemon is specified. The default is /etc/rsyncd.conf unless the daemon is running over a remote shell program and the remote user is not the super-user; in that case the default is rsyncd.conf in the current directory (typically $HOME). That behavior of loading rsyncd.conf from the current directory was the piece I had missed before. Well, in my case I had the following setting in rsyncd.conf: path = /backup/synology where path points to a different directory which is NOT $home nor doesn't permit to reach $home. So you cannot overwrite /home/synology/rsyncd.conf. Well... provided that "path" config is not affected by path
traversal ("../../home/synology"). At least, what I understand
from rsyncd.conf manual is that it shouldn't be possible: rsyncd.conf .
user=synology:022:100000: # rsync, with no chroot So rssh shouldn't permit to use scp or other methods in order to
overwrite rsyncd.conf.
My setup seems safe (am I missing something?).
Presumably, this is exactly the behavior that Synology relies on, but this means that if the client can write to this configuration file, it can just include a pre-xfer exec setting in that rsyncd.conf file and run commands on the server side. Not in my setup.
So, unfortunately we won't be able to fix Synology in a stable update, since it was relying on insecure behavior. I'll continue with an update to fix the libssh2 regression. I don't know how many people is using rssh (I guess not that many), but if we limit its use more, it will probably die (it will probably die in either case :-)). Cheers, -Román
|