Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.security > #5556

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

From Roman Medina-Heigl Hernandez <roman@rs-labs.com>
Newsgroups linux.debian.security
Subject Re: rssh security update breaks rsync via Synology's "hyper backup"
Date 2019-02-19 16:10 +0100
Message-ID <xtfbY-6qu-1@gated-at.bofh.it> (permalink)
References (4 earlier) <xrtCp-1uM-1@gated-at.bofh.it> <xruf7-1Hx-1@gated-at.bofh.it> <xsUTU-2OO-23@gated-at.bofh.it> <xsVZD-3p9-1@gated-at.bofh.it> <xt46R-8mB-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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




Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

rssh security update breaks rsync via Synology's "hyper backup" Roman Medina-Heigl Hernandez <roman@rs-labs.com> - 2019-02-14 18:20 +0100
  Re: rssh security update breaks rsync via Synology's "hyper backup" Holger Levsen <holger@layer-acht.org> - 2019-02-14 18:40 +0100
    Re: rssh security update breaks rsync via Synology's "hyper backup" Chris Lamb <lamby@debian.org> - 2019-02-14 18:50 +0100
      Re: rssh security update breaks rsync via Synology's "hyper backup" Roman Medina-Heigl Hernandez <roman@rs-labs.com> - 2019-02-14 19:00 +0100
        Re: rssh security update breaks rsync via Synology's "hyper backup" Russ Allbery <rra@debian.org> - 2019-02-14 19:10 +0100
          Re: rssh security update breaks rsync via Synology's "hyper backup" Antoine Beaupré <anarcat@orangeseeds.org> - 2019-02-14 19:50 +0100
            Re: rssh security update breaks rsync via Synology's "hyper backup" Russ Allbery <rra@debian.org> - 2019-02-18 18:30 +0100
              Re: rssh security update breaks rsync via Synology's "hyper backup" Roman Medina-Heigl Hernandez <roman@rs-labs.com> - 2019-02-18 19:40 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Russ Allbery <rra@debian.org> - 2019-02-19 04:20 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Roman Medina-Heigl Hernandez <roman@rs-labs.com> - 2019-02-19 16:10 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Russ Allbery <rra@debian.org> - 2019-02-19 17:50 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Roman Medina-Heigl Hernandez <roman@rs-labs.com> - 2019-02-20 19:20 +0100
              Re: rssh security update breaks rsync via Synology's "hyper backup" Antoine Beaupré <anarcat@orangeseeds.org> - 2019-02-18 22:10 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Chris Lamb <lamby@debian.org> - 2019-02-18 22:30 +0100
              Re: rssh security update breaks rsync via Synology's "hyper backup" Russ Allbery <eagle@eyrie.org> - 2019-02-19 06:00 +0100
                Re: rssh security update breaks rsync via Synology's "hyper backup" Chris Lamb <lamby@debian.org> - 2019-02-19 09:20 +0100

csiph-web