4 ms·
> 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
by reader_1000 6y ago
> 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.
- SoSoRoCoCo 6y ago> 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?