Don't Copy Paste into a Shell | Hacker News Reader

Don't Copy Paste into a Shell

briantracy.xyz

31 pointsoweiler8 comments

There's a terminal mechanism to avoid this kind of attack: Bracketed Paste Mode. https://cirw.in/blog/bracketed-paste

A few terminals, despite having Bracketed Paste Mode, are vulnerable to escape injection. That's when the end-paste escape sequence is included in the paste content, and the terminal lets it pass through, causing the shell to think the paste ended.

Urxvt is one such terminal with that vulnerability, but it can be fixed with a small perl extension, like the one I provided here:

https://security.stackexchange.com/questions/39118/how-can-i...

That answer also includes a table checking other terminals for that vulnerability.

The second example on the following page can be used to test a terminal for that variation of the attack:

https://thejh.net/misc/website-terminal-copy-paste

Some terminal emulators strip control codes (like \\n) from pastes for this reason. Alacrity and konsole do this, at least.

Also, javascript isn't heeded for this vulnerability. https://thejh.net/misc/website-terminal-copy-paste is a link that demonstrates this with plain html, and has been discussed on HN before.

Apologies, it seems you already have that link. I have a bad habit of skimming, posting, and then hastily editing after re-reading the parent comment. I'll be more careful about that in the future.

> Some terminal emulators strip control codes (like \\n) from pastes for this reason. Alacrity and konsole do this, at least.

I can paste newlines just fine in both alacritty and konsole, so I'm not sure what you mean. With support for Bracketed Paste Mode, all that needs to be stripped from the pasted content is the end-paste escape sequence.

Perhaps they stripped newlines before adding Bracketed Paste Mode. That must've been quite some time ago, though.

> I can paste newlines just fine in both alacritty and konsole, so I'm not sure what you mean.

That's strange. I tried copy-pasting the text on https://thejh.net/misc/website-terminal-copy-paste to Alacritty, and the newlines were replaced with semicolons. However, pasting newlines worked within vim in insert mode. It happens with or without bracketed paste mode on (using the "enable-bracketed-paste" option in ~/.inputrc). Same thing with Konsole.

> > A few terminals, despite having Bracketed Paste Mode, are vulnerable to escape injection. That's when the end-paste escape sequence is included in the paste content, and the terminal lets it pass through, causing the shell to think the paste ended.

I'm glad you mentioned this!

> With support for Bracketed Paste Mode, all that needs to be stripped from the pasted content is the end-paste escape sequence.

Alacritty strips the control sequence that ends bracketed paste; https://github.com/alacritty/alacritty/issues/800.

> It happens with or without bracketed paste mode on (using the "enable-bracketed-paste" option in ~/.inputrc).

~/.inputrc is the readline library's configuration file. The "enable-bracketed-paste" option in it doesn't affect vim nor the terminals. What it does is turn on the recognition of Bracketed Paste Mode escape sequences for programs that use readline, like bash.

> the newlines were replaced with semicolons

I can't reproduce. After setting that option in ~/.inputrc, bash puts multi-line pastes in a single prompt, but it keeps the newlines, not replace them. This is bash 5.0.18(1). Are you sure you're not confusing the semicolons that are really there and thinking they were newlines before?

In any case, a behavior like that would have to be done by the shell, not the terminal, since semicolons are not special to the terminal and it's not a simple matter of substituting one for the other in shell code. In order for the shell code to be equivalent, parsing would be required to identify if the newline terminates a command or if it's part of another syntax structure. For example

  foo
  bar='
  baz
  '
  qux << EOF
  quux
  EOF

only 2 of the newlines above can be substituted with semicolons.

EDIT: Maybe you have other bash configuration options playing into that substituting behavior. Bash shell options like cmdhist and lithist seem relevant. From the bash manpage:

> lithist If set, and the cmdhist option is enabled, multi-line commands are saved to the history with embedded newlines rather than using semicolon separators where possible.

This is a bad form of advice. Instead of "Don't do X", it's much better to say "Do Y instead of X".

So in this case, for instance, it's safer to first paste into a text editor, examine first, then paste.

Reply on news.ycombinator.com