Many terminal emulators are not very good at dealing with unstrusted input.

http://www.openwall.com/lists/oss-security/2017/05/01/13

There used to be some terminal emulators that supported "screen dump", where the scrollback buffer would be written to an arbitrary named file.

echo -e "\ec\n\e]55;/tmp/ouch.php\a"

I believe they've all removed that functionality by now, but there might be some older copies around here and there.

IIRC, another angle that has been proposed is to switch between the primary and secondary terminal buffers. This way, one could create a file that looks harmless when piped to the terminal but contains a hidden, malicious payload. The victim would, after manual inspection, finally pipe the file to a shell, where the payload would do something evil.

> The victim would, after manual inspection, finally pipe the file to a shell

Why would anyone do this? If I see some unknown, interesting file, I might run cat, head, tail, less or vim on it. If it's binary then maybe I'll use xxd. But it wouldn't even occur for me to pipe it to a shell.

As people tend to re-use shell commands, editing them as they go, I can totally see someone doing like curl XX | less and then curl XX | sh or something. If the download is relatively speedy.

You could argue this is one of the reasons less doesn't interpret control codes by default. As it would let applications hide stuff like that to redraw the screen.

You could use the script command. (Which is also very helpful for running screen under su.)