5 ms·
Checking out the mitigation for CVE-2019-6111 [1], how does `sftp` help? * scp(1): Relating to the above changes to scp(1); the scp protocol relies
by bArray 8y ago
Checking out the mitigation for CVE-2019-6111 [1], how does `sftp` help?
* scp(1): Relating to the above changes to scp(1); the scp protocol
relies on the remote shell for wildcard expansion, so there is no
infallible way for the client's wildcard matching to perfectly
reflect the server's. If there is a difference between client and
server wildcard expansion, the client may refuse files from the
server. For this reason, we have provided a new "-T" flag to scp
that disables these client-side checks at the risk of
reintroducing the attack described above.
You could just do a remote `ls` and then `sftp` all the files listed to your client - nothing stopping a malicious return from `ls`? Surely it's the risk of running any kind of wild card copy? If the server is compromised then there's no telling what will be returned from such a command?
The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.
The protocol itself might be outdated, but surely one of the best aspects of `scp` comes from its simplicity [2]?
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111
[2] https://github.com/openssh/openssh-portable/blob/master/scp.c https://github.com/openssh/openssh-portable/blob/master/scp....
- djmdjm 8y agoscp only appears to have simplicity because it outsources large parts of its functionality (e.g. glob expansion) to the destination host's shell. scp/rcp was a great protocol for 1981 (yes, that's when it was introduced) but not for 2019
- tgragnato 8y agoAnd this leads to the question.. OpenBSD is famous for removing unwanted or outdated code. What makes scp a special case? Is it too used to be deprecated and removed?
- djmdjm 8y agoyeah, pretty much. If someone implemented scp's command-line with sftp underneath then we could start the (slow) deprecation process.
- throwaway2048 8y agoits part of the ssh protocol, getting rid of cruft from network protocols is almost completely impossible unfortunately, because its going to destroy many people's workflows, in a way that they can not fix, guaranteed. Yes, we all know about xkcd, no need to link guys.
- djmdjm 8y agoscp isn't part of the ssh protocol. It's a command that runs over it.
- Operyl 8y agoOut of curiosity, since I wasn't sure which one in particular throwaway2048 was talking about, here are my closest guesses: 927 - Standards - https://xkcd.com/927/ https://xkcd.com/927/ 1127 - Workflow - https://xkcd.com/1172/ https://xkcd.com/1172/ 1323 - Protocol - https://xkcd.com/1323/ https://xkcd.com/1323/
- boomlinde 8y agoIMO sftp is underspecified. The 14 IETF drafts that exist for it have all expired and never reached RFC status. In practice, this means that the OpenSSH implementation is the de facto standard, and that interoperating a non-OpenSSH client with a non-OpenSSH server is a gamble. It's interesting that they push for sftp. Personally, if scp is vulnerable to certain types of attacks, I'd rather see an entirely new standard and an effort to avoid having it in draft state for decades.
- axaxs 8y agoI'm not sure SCP is specified at all, though. I recently wrote a true SCP client for Go (not SFTP, which oddly enough all the other "SCP" clients for Go use). The only documentation I could find at all was a single blog post from a guy who worked at Oracle.
- throwaway2048 8y agosftp died in IETF draft because they kept tacking on outdated and misguided concepts from the original FTP like ASCII/binary transfer mode and record file types(really guys, when was the last time an operating system that used this was popular, the 1980s?), as well as tons of other completely pointless cruft to an otherwise very clean protocol, so OpenSSH decided to stay at draft version 3, and being as they are the dominant implementation by far, the effort died. I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well.
- boomlinde 8y ago> I'm not sure why we need to see an entirely new standard, sftp as implemented by openssh is well conceived, simple, and covers its use case very well. The key to my point here is "as implemented by openssh". A relevant anecdote: I had to connect from my program to a third party (version 3) SFTP service, IIRC backed by some Oracle software (but don't quote me on that). I had a version 3 client library. The OpenSSH client worked just fine with the remote, and the client library worked just fine with an OpenSSH server. When connecting to the third party, the client gave up. After some debugging I learned that the third party server didn't include the language tag in its response statuses (as SFTP version 3 software should). OpenSSH was just fine with this and ignored the problem, and the third party software was probably only ever tested with OpenSSH based clients. It was definitely a bug in the third party service as far as I was concerned, but I think that this is the natural result of relying on behavior "as implemented by ssh" rather than a stable, well defined (and non-expired) standard.