On Fri, 20 Oct 2023 at 09:55, Turistu <turistu () gmail com> wrote: [...] It pretty much is mitigated at that layer. If xterm itself weren't filtering out the ESC (ascii 0x1b) character in the pasted data, then the bracketed-paste feature of bash or zsh could've been easily bypassed by inserting a "\x1b[201~" escape (= end of pasted data) in the payload. (As already mentioned in the report too). I haven't tested all terminal and shell combinations, but the implementations of bracketed paste mode vary in their correctness, some do not filter all non-whitespace control characters, so for example you can add ^C into the exploit HTML:

writeXPrimary('\u0003;touch ~/LOL-' + Date.now() / 1000 +'\r')

Then you get a command being run with no interaction; this appears to work with xterm (384) + fish for example. But there are a thousand more ways for an attacker to leverage that hole in Firefox. Many programs (including Firefox itself!) could be easily crashed by garbage data from the clipboard. Attacker-controlled data could find its way into shell scripts via var=$(xsel), etc. This isn't just limited to Firefox, one example is terminals that support OSC 52 (clipboard write), a remote SSH session can be hijacked and an attacker can inject OSC 52 into the stream in the background (I looked into this as part of my terminal security research, see [1]).

As you point out there are many ways for untrusted data to end up on the clipboard, the attack vector here is via the terminal so my opinion is the terminal is what should protect against it. (Although I think Firefox could help with some defense-in-depth here, shame they don't want to.)

For example two terminals that get this right are:

- rxvt-unicode: The confirm-paste extension (loaded in the default set) pops up a confirmation when pasting control characters (not just newlines), "y" will strip controls, "p" will paste controls as is. - Windows Terminal: Strips non-whitespace control characters, asks for confirmation when pasting newlines, if bracketed paste mode is off.

David

[1]: https://dgl.cx/2023/09/ansi-terminal-security#xterm-osc-52-clipboard

xterm before 380 supports ReGIS reporting for character-set names even if they have unexpected characters (i.e., neither alphanumeric nor underscore), aka a pointer/overflow issue. This can only occur for xterm installations that are configured at compile time to use a certain experimental feature.

xterm before 375 allows code execution via font ops, e.g., because an OSC 50 response may have Ctrl-g and therefore lead to command execution within the vi line-editing mode of Zsh. NOTE: font ops are not allowed in the xterm default configurations of some Linux distributions.

https://invisible-island.net/xterm/xterm.log.html https://www.openwall.com/lists/oss-security/2022/11/10/1 https://news.ycombinator.com/item?id=33546415 http://www.openwall.com/lists/oss-security/2022/11/10/1 http://www.openwall.com/lists/oss-security/2022/11/10/5

xterm through Patch 370, when Sixel support is enabled, allows attackers to trigger a buffer overflow in setsixel in graphicssixel.c via crafted text.

A crash was reported in xterm prior to patch #366 when processing a specially crafted sequence of combining characters. The cause is an out of bounds write, which may be exploitable to cause arbitrary code execution.

https://www.openwall.com/lists/oss-security/2021/02/09/7 https://invisible-island.net/xterm/xterm.log.html

CRLF injection vulnerability in xterm allows user-assisted attackers to execute arbitrary commands via LF (aka \n) characters surrounding a command name within a Device Control Request Status String (DECRQSS) escape sequence in a text file, a related issue to CVE-2003-0063 and CVE-2003-0071.