6

Given that control characters are usually not rendered, but they are given a special meaning in most terminals, what reasons are there for terminal apps to continue to support copy-pasting of control characters?

One can mask a harmful code as described here for example, so that it causes issues when pasted into a terminal.

The issue that causes this is twofold:

  • Chrome doesn't render the ^H character, making one expect that the copied text is something different.
  • gnome-terminal (or xterm) dutifully accepts it from the user as if it was direct keyboard input, executing the control characters

Why does the terminal do this? Are there any use cases for being able to paste control characters (other than \t,\r,\n) into a terminal?

Community
  • 1
Manishearth
  • 8,237
  • 5
  • 34
  • 56
  • 2
    Ringing the bell, obviously. Jingle \as, jingle \as, Jingle all the way. Oh! what fun it is to ride In a one-horse open sleigh. – Deer Hunter Feb 07 '14 at 09:16
  • No particular comment on why they do, but just wanted to add that some editors will display control characters with their own glyph, to alert the fact that they are there. – Owen Feb 07 '14 at 12:04

4 Answers4

4

Terminals pre-date copy and paste. So within the terminal protocol, there is no distinction between pasting versus typing. The idea of pasting content into a terminal emulator window was retrofit into the system by simulating the rapid typing of characters when the terminal when the "paste" function is activated. This just dumps the content in exactly as it appears in the clipboard.

As for pasting control characters: the response of the terminal emulator's programmer would be something along the lines of, "Why would you even do that?" You make a compelling argument that this could actually be an injection vulnerability in the terminal program itself.

As such, it's not out-of-the-question to suggest that programs like PuTTY and GNOME Terminal should have a setting somewhere which allows you to specify whether or not pasting of control characters is something you want to enable. Perhaps disabled by default.

tylerl
  • 82,225
  • 25
  • 148
  • 226
3

I believe this is a good question, since it has a lot of systems involved. In which court is it the ball? Is this really a problem? I have never thought about this, but let me spit some thoughts.

  1. I believe that copy&paste is a tool, and since it is a tool I believe it may be useful to copy&paste control chars from a place to another. Maybe, in example, you want to copy a shell script recipe and paste it into your terminal or your "notes application".

  2. About security implications. Of course there are, you might be copying something you don't know if it is harming and in fact it is hidden so it can trick advanced users so, is this as simple as adding a warning when copying/pasting control characters? Should an especial string be painted whenever it finds a control character? Well, I guess it will depend on the application we consider.

I hope this answer inspire someone else to express inner thoughts, I will be upgrading this answer if I feel I can add some more valuable thoughts.

kiBytes
  • 3,450
  • 15
  • 26
3

Terminals allow arbitrary input because they are exactly that: terminals. They emulate old physical devices which work over a serial line. Copy-paste was just forcefully pushed into that model, with no actual thought about security.

In fact, in the old-timer Unix+X11 model, security was ensured by preventing outsiders from sending synthetic events. That the user himself is copy-pasting evil data snippets was not considered as a threat.

Terminals will begin to take care if some actual attack occurs, forcing developers to take action in order to avoid utter ridicule.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
1

Regarding:

Are there any use cases for being able to paste control characters (other than \t,\r,\n) into a terminal?

Your interaction with TUIs is via these control characters. Being able to paste them means you can use this feature to semi-automate your interaction with TUI programs.

Some time ago, I saved my department many hours of hurried work of manually entering hundreds of records of multiple fields in TUI forms, by taking the data we needed to enter from a CSV, interpolating the control characters needed to navigate the TUI (via sed I think), validating the result, and pasting it into the terminal. All taking a few minutes.

Showing them this was like adding an import feature to every form of the TUI program. They found it to be a very useful technique, a real timesaver.

Depending on the case, though, this might be kind of dangerous. If an input value is invalid or a control sequence is wrong and the TUI program responds unexpectedly, the paste won't quit; it'll keep going and do who knows what with the TUI program.

In our case, it was simple to ensure that the inputs were valid, testing a cycle (enough of the paste to input 1 record and return to starting position) was enough to also ensure that the control characters were ok, and we also took a moment to consider the worst that could happen if at any point this particular paste could be interpreted out of context.

This was a quick and dirty ad-hoc solution to a somewhat rare problem. Given more time, it might've been better to learn how to write expect scripts first to at least quit on the first detected error and report where it got stuck. We were somewhat in a hurry though, so we couldn't consider something that we needed to invest time learning first, especially when we already accepted how long it would take to do it manually. The simplicity and ease of pasting our interaction with a TUI in a few minutes is what provided value over using an expect script.

JoL
  • 242
  • 2
  • 7