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

[Antoine Beaupré <anarcat@orangeseeds.org>]

On 2019-02-14 10:08:40, Russ Allbery wrote:
> 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.)

Thanks for the detailed analysis Russ! It does seem to be a bit of a
whack-a-mole game that would be better solved by proper use of
`command`...

That said, if we do fix this in jessie, we should do it at the same time
as the regression identified in stretch (DSA-4377-2).

Russ, do you want to handle the Jessie update or should the LTS team do
it?

Should we wait for resolution on this issue before shipping the errata?

Thanks!

-- 
In serious work commanding and discipline are of little avail.
                         - Peter Kropotkin