4 ms·

I have wondered if there are security hazards to piping binary to your terminal. I guess what really bad things can happen (and no I'm not talking about blindl

I have wondered if there are security hazards to piping binary to your terminal. I guess what really bad things can happen (and no I'm not talking about blindly piping to a shell to eval)? Sure it messes up the terminal of which I usually type clear and/or reset. If it's really bad I usually just kill the terminal.

jwilk 9y ago
Many terminal emulators are not very good at dealing with unstrusted input. http://www.openwall.com/lists/oss-security/2017/05/01/13 http://www.openwall.com/lists/oss-security/2017/05/01/13
tyingq 9y ago
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.
- eigengrau 9y ago
  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.
  - joombaga 9y ago
    > 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.
    - lathiat 9y ago
      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.
- Dylan16807 9y ago
  You could use the script command. (Which is also very helpful for running screen under su.)

jwilk 9y ago

Many terminal emulators are not very good at dealing with unstrusted input. http://www.openwall.com/lists/oss-security/2017/05/01/13 http://www.openwall.com/lists/oss-security/2017/05/01/13

tyingq 9y ago

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.

eigengrau 9y ago
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.
- joombaga 9y ago
  > 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.
  - lathiat 9y ago
    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.
Dylan16807 9y ago
You could use the script command. (Which is also very helpful for running screen under su.)