On 2019-02-14 10:08:40, Russ Allbery wrote: > Roman Medina-Heigl Hernandez <ro...@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