Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

When SSHing to a host that has been compromised (or outright replaced using the stolen server keys) by an attacker with root permissions, what is the worst that can happen to the client?

It is well known that X forwarding poses some risks, and agent forwarding is obviously a bad idea in that scenario, but are there more issues?

  • What information can be gained about the client, in addition to environment variables set by ssh (SSH_CONNECTION, everything from ~/.ssh/environment)?
  • What can be accomplished with terminal escape sequences?
  • How hard is it to fake a logout (in response to CTRL+D, logout etc.) to the client, thereby provoking a user to execute additional commands with potentially sensitive inputs on the remote host, like sudo with a password entry? Can the client's prompt be read remotely to make such a deceit more convincing?
  • Are there any effective ways to prevent such deceit, like aliasing ssh to "ssh; echo somesecret"?
share|improve this question
add comment

1 Answer

up vote 7 down vote accepted

Intercepting the "logout" commands is easy on the hostile server. Intercepting the "Ctrl-D" requires taking control of the terminal in raw mode, but that's not a big issue.

Reading back the terminal contents might prove difficult. Different terminals implement their own set of control sequences; xterm is notorious for implementing a lot of them. I don't see any sequence which allows reading back the terminal contents; however, some considerable messing up can still be done with the sequences, such as moving the window around, switching fonts, and so on. In older days, it was possible to actually make xterm create local files, albeit without much control on the file name (I don't remember the details, but it was probably with the "log files" feature which may be disabled at compile-time). Besides dancing, an xterm could be made to sing, too, with the "bell character" -- it is more a nuisance thing than an attack vector, though.

Speaking about nuisance: depending on the client system and its configuration and graphic drivers, a rogue terminal scrolling text at high speed may all but freeze the victim's console (in my experience, gnome-terminal and a compositing window manager can turn into a bad combination for that).

Still in xterm, there are sequences to manipulate the clipboard (search for "manipulate selection" in the reference page linked above). This can be nasty, both for reading and for writing. See this page for a discussion about the possible issues (an issue-tracking list of comments, from people discussing the possibility of importing that mechanism in a terminal emulator called mintty).


The overall conclusion is: do not SSH into insecure hosts. If you do, you may want to do that from rxvt-unicode, an rxvt fork where the author made (among other features) some effort at disabling "insecure" control sequences by default (they can be brought back with the "-insecure" command-line parameter).

share|improve this answer
    
Don't forget agent forwarding –  tylerl Jun 28 '13 at 18:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.