Marvin <tbglosth...@yahoo.co.uk> writes: > Since our fileserver auto patched to rssh 2.3.4-4+deb8u2 this morning, > our automated scp requests have been failing if we try get multiple > files from the server in one wildcarded request.
> So to recreate > --------- > $ scp u...@example.com://directory//file.x86_64_*.*.zip . > The authenticity of host 'example.com (192.168.60.224)' can't be established. > ECDSA key fingerprint is ######################## > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added 'example.com (192.168.60.224)' (ECDSA) to the list > of known hosts. > insecure scp option not allowed. > This account is restricted by rssh. > Allowed commands: scp sftp rsync > If you believe this is in error, please contact your system administrator. > ---------- > where example.com://directory//file.x86_64_*.*.zip matched 2 or more files Ugh, yeah, that's going to be a problem. The attempt here was to prevent scp commands that initiate outbound ssh connections on the server, such as syntax like "scp foo.txt remote:foo.txt" sent to the server, which can lead to arbitrary code execution. But it looks like the client sends multiple arguments to the server in the multiple file download case. I may be able to instead reject multiple file arguments if any contain a colon. > Moving files from the fileserver until there's only one match results in > a successful download. Not using wildcards is also ok. Does not using wildcards even when listing multiple files to download still work? Are you using a chroot? > This is on an Ubuntu14:04 machine. I've marked it "severity important" > as it's a regression that caused a set of 3 fileservers who'd been happy > for ~ 5 years to stop serving the required files and took a fair while > to debug as this was an automated process and we didn't suspect a > fileservr change for a fair while. Yeah, I'm sorry about that. Unfortunately, the security vulnerability was fairly nasty, and I overlooked that use case. Please be aware that rssh is going to be removed from Debian before the next stable release because it's orphaned upstream and is essentially unsupportable from a security standpoint. Time has proven its security model to be far too fragile; we're seeing a regular stream of security vulnerabilities, and I suspect there are a lot more that we just haven't found yet. You're therefore unfortunately going to have to start thinking about a migration plan, although I'm going to try to keep it limping along for the lifetime of stable. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
