Re: rssh security update breaks rsync via Synology's "hyper backup"
Roman Medina-Heigl Hernandez <roman@rs-labs.com> writes:
> Added Russ (rssh maintainer).
> I cannot probe it but I guess chances are high that the issue is present
> both in stable and oldstable (I cannot find a good reason to filter
> different commands: solution should be the same or very similar) so I'm
> still keeping debian-security in the loop.
That command line exactly is probably safe, but --daemon is definitely not
safe in combination with --config, -M, or --dparam. I'm not sure what
happens if you pass combinations like --server --daemon --address or
--port. Unfortunately, so far as I can tell, --server --daemon is not
even documented in the rsync man page as something you can do (I certainly
didn't know about its existence before this string of CVEs), so it's
pretty hard to figure out what its intended behavior is without doing a
deep dive into source code.
We can try to make the command-line verification even more complex to try
to allow for more edge cases (another one just came up in an Ubuntu bug,
where libssh apparently sends arguments differently than scp itself does).
I'm not super-thrilled, but I guess I created this problem and signed up
for it, so I can try to keep playing whack-a-mole with new command-line
variations.
Note that I'm definitely removing rssh from unstable and testing before
the next release as unsupportable. Upstream has orphaned it, and I think
the primitive that it's attempting to implement is fundamentally
impossible to maintain securely. So the long-term solution is for
everyone to migrate away from it, I'm afraid; the question is what to do
about stable (and oldstable).
In this particular case, a simple command="rsync --server --daemon ." in
your ssh authorized_keys file might be a better solution than rssh. (But
be aware of CVE-2019-3463.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: