[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rssh security update breaks rsync via Synology's "hyper backup"



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





    

Reply to: