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

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

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

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

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


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

Reply to: