Who's them? So I did some digging on my own and I managed to uncover this statement from Theo de Raadt:
commit 82ff5eac51d41356a89ceffe2102c69616946320
Author: deraadt <[email protected]>
Date: Sat Oct 3 02:18:33 2020 +0000
split introductory paragraph, and insert ominous words about the glob
issue, which cannot be fully fixed and really requires completely
replacing scp with a completely different subsystem.
team effort to find the right words..
Why doesn't the LWN article talk about that? It sounds like this glob thing is the real deal-breaker for the OpenSSH team.
The CVE-2020-15778 GitHub page attributed it to the OpenSSH team. Corbet quoted the OpenSSH 8.0 release notes too.
The glob issue is the backtick issue. The protocol requires running the remote user's shell to expand globs. Running the remote user's shell expands backticks.
Would it be possible to expand globs in a different way then? Say manually? Or with escaped backticks? I kind of think it's worth breaking people's workflows here, but idk.
Edit: I guess this is what the sftp-based scp does. But I wonder if the problems could be fixed without changing protocols.
Easier would be to disable backticks per default and only allow them with the new -T option which was added recently to permit case-insensitivity problems.
> I kind of think it's worth breaking people's workflows here, but idk.
Why? As many times mentioned in these replies there are a dozen alternatives if you just want file transfer. Why break argument parsing in scp when those alternatives are readily available?
Seems preferable to evolve it in line with how 99% of people are using it, rather than deprecate it because 1% of people are using it in a dangerous way.
It's also a shame to waste a nice 3-char name that, as the article puts it "is deeply wired into the fingers of many Linux users and developers"
> Finally, while the danger is remote, it is worth noting that a local file name containing `backticks` (a file named `touch you-lose`, for example) will be handled the same way on the other end; if a user can be convinced to perform a recursive copy of a directory tree containing a file with a malicious name, bad things can happen.
If tricking the user is the issue then we should also symlink ssh to chrome. Would be a waste to loose an otherwise fine three letter name to something as dangerous as giving someone direct remote access to a system.