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:
**path**
This parameter specifies the directory in the daemon's filesystem to
make available in this module. You must specify this parameter for
each module in |rsyncd.conf|.
At the same time, my /etc/rssh.conf has:
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
