Created attachment 2955 [details] Patch to make escape char forward menu optional Hello, attached patch adds the ability to disable the escape char based forward menu. People in support departments routinely ssh into remote machines that could be potentially compromised by an attacker. If a lengthy process is started in a terminal emulator like screen(1) or tmux, an attacker might inject escape sequences to create port forwardings to bypass local firewalls completely. The attacker might cause a "fault" that will make use of screen(1) more likely when f.e. trashing a software RAID on purpose. Prevent the attack by making the forward menu optional, so it can be disabled. The menu is enabled by default for compatibility reasons, though I recommend to disable it in an upcoming release. I've asked around a few sysadmin friends and none of them has ever heard about the ~C menu. All of the routinely use screen(1) on jump boxes though. Demo exploit using screen(1) can be found here: https://0xicf.wordpress.com/2015/03/13/hijacking-ssh-to-inject-port-forwards/ Please consider this patch for upstream inclusion. Cheers, Thomas
I don't think this adds much - a nefarious client could use the connection multiplexing options, ptrace or even netcat to achieve the same outcome. IMO if you want to disable forwarding then the place to do it is on the server and we offer controls for that already. BTW, the page you linked is all post-exploitation attacks. These are almost always pointless to defend against, because the attacker has so much more leverage than the defender.
Yes, it's true that once the machine is compromised, the attacker can replace / patch any binary file as he pleases. The worrysome part is the second attack stated in "Hijacking Active SSH Sessions". -> Is there filtering in the ssh client to prevent a remote host to send the escape sequence for '~C' back to the client? If so, I'm wondering a) what I tested back then in February and b) the patch would not be needed. Or may be it was possible to trigger ~C from the remote server as I used screen on the local side, too?
No, ~C happens solely in the client and the server can't trigger it
(In reply to Damien Miller from comment #3) > No, ~C happens solely in the client and the server can't trigger it If your terminal has escape-programmable answerback sequences it might. I dunno if any of those still exist though.
close bugs that were resolved in OpenSSH 8.5 release cycle