Comment by SoSoRoCoCo | Hacker News Reader

Comment by SoSoRoCoCo | Hacker News Reader

The problems outlined by the article do not at all seem significant enough to merit a full scale deprecation of scp. The article states that beside file duplication on the source machine, the only security issue is the same as having any SSH access on the machine. The other issue (the bashrc example) is akin to a bonehead move like accidentally typing rm -rf somewhere important. `scp` doesn't need a gun lock, IMHO, just an attentive user, like any command, really.

This comment made me chuckle:

> Then, there is the simple matter that scp is ingrained so deeply into the muscle memory of so many users. As with other deprecated commands (ifconfig, say), it can be hard to make the switch.

Trying to wean myself off ifconfig to ip & netplan has been effing brutal since network provisioning is something I do less than once a quarter.

Similarly, I've been trying to 'train' myself to use rsync since ... checks notes ... ~2004, and I still have to stop, clear my head, and read the man page to figure it out because it is useful for huge transfers, but those are so rare in my flow.

Don't you bring netplan into this! The ifconfig -> ip transition is at least an improvement. Canonical had every chance to use NetworkManager which is battle-tested, has an extremely polished language bindings, a cli, tui and multiple GUIs, handles complex configurations like a champ, has a nice connection plug-in system to handle all kinds of less common stuff like VPNs, Bluetooth, Wi-Fi sharing, IPoDNS and a plug-in system to support reading configs in other formats (like maybe YAML for instance). The plug-in ifcfg-rh is the reason why ifcfg scripts all still work.

But no, they wrote this entirely non-extensible basically trivial C utility (that's not a dig, seriously look at the code, it does almost nothing!) that doesn't reduce complexity at all since it's the thinnest possible abstraction over its backends and adds yet another layer of things that might fail. But it's integrated into cloud-init by default so it's easier to just slog though fighting it than to rip it out.

> The other issue (the bashrc example) is akin to a bonehead move like accidentally typing rm -rf somewhere important.

I think you've misunderstood the issue a little bit. Dangerous command is this: scp admin:boring-spreadsheet.ods .

Here, user do not do type anything wrong, however if an attacker somehow replaces the remote with a malicious ssh server which returns a .bashrc that contains dangerous content (such as aliases like alias ls=rm -rf *) then you are basically screwed. So this is a serious issue.

Other security error is quite interesting if I understood it correctly (scp some-local-file remote:'`touch you-lose`remote-file'). It is basically running the command in the remote server. If that is so, why would a file transfer protocol run a command in the remote server? If an attacker manages to put a file with name `rm -rf /` in the directory that one is going to transfer, it may damage the remote system. I think, this part of protocol really needs to be fixed.

> I think you've misunderstood the issue a little bit.

I might be misunderstanding this. How does .bashrc get replaced in that example? You mean the hijacked remote returns .bashrc instead of boring-spreadsheet.ods? That means it is only a problem if you are in $HOME (but still a problem). Further, how does the remote complete the SSL handshake if it doesn't have the private key, and if it does, isn't that a bigger problem?

Reply on news.ycombinator.com