Bug 2691

Summary: Add ability to disable escape char forward menu
Product: Portable OpenSSH Reporter: Thomas Jarosch <thomas.jarosch>
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED WONTFIX    
Severity: security CC: djm, dtucker
Priority: P5    
Version: 7.4p1   
Hardware: Other   
OS: Linux   
Attachments:
Description Flags
Patch to make escape char forward menu optional none

Description Thomas Jarosch 2017-03-08 09:16:25 AEDT 
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
Comment 1 Damien Miller 2017-03-10 13:15:51 AEDT 
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.
Comment 2 Thomas Jarosch 2017-03-14 05:34:20 AEDT 
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?
Comment 3 Damien Miller 2018-01-05 15:02:47 AEDT 
No, ~C happens solely in the client and the server can't trigger it
Comment 4 Darren Tucker 2018-01-05 15:05:03 AEDT 
(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.
Comment 5 Damien Miller 2021-03-04 09:54:42 AEDT 
close bugs that were resolved in OpenSSH 8.5 release cycle