Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sometimes when I cat a binary file by mistake, my terminal gets garbled up. Nothing a quick reset can't fix, but couldn't an attacker theoretically create a file that, when displayed on a terminal, would execute some arbitrary code? Through an exploit in the terminal emulator or otherwise.

share|improve this question
Sometimes when I do that my shell will say at the end "<garbage> unknown command". That makes me wonder if this is actually possible. – Keith Apr 26 '13 at 5:49
There were exploits for the terminal emulator, e.g. or so it is not necessary particular safe – Ulrich Dangel Apr 26 '13 at 8:11
This is why it's better to use something that will balk at binary files (like more) or is terminal-aware (less) to examine the contents of files. Not only will it not put your terminal in a weird state, the whole file won't go flying by in one shot. – Blrfl Apr 26 '13 at 14:20
The stty sane command resets an xterm (or similar) which has been switched into e.g. a different character set. – Thorbjørn Ravn Andersen Jan 1 at 17:22

7 Answers 7

up vote 29 down vote accepted

Whether such output can be exploited depends on the terminal program, and what that terminal does depending on escape codes that are being sent. I am not aware of terminal programs having such exploitable features, and the only problem now would be if there is an unknown buffer overflow or something like that, that could be exploited.

With some older hardware terminals this could be a problem as you programmed e.g. function keys with these kind of escape sequences, by storing a command sequence for that key in the hardware. You would still need a physical key-press to activate that.

But there are always (as Hauke so righfully marked 'braindead') people willing to add such a feature if it solves a problem for them, not understanding the loophole they create. In my experience with open source software is that, because of the many eyes looking at the code, this is less likely to happen as with closed source. (I remember that in the mail program on Silicon Grahpics' Irix, in the mid ninetees, you could include commands to be executed on the receivers machine, real paths to executables, ....)

share|improve this answer
"you could include commands to be executed on the receivers machine" You mean something like including in an email VBScript that calls out to the Windows Scripting Host? :) – Michael Kjörling Apr 26 '13 at 7:46
No exactly, you could start an executable that was already on the machine, like playing a sound. I don't recall the exact syntax (that was almost 20 years ago) nor whether you could switch that 'feature' off in a setup. We had some fun though with auto-playing videos stored in our network. – Anthon Apr 26 '13 at 7:54
You're not talking about NeWS are you? IIRC SGI was one of the last hold-outs. – luser droog Apr 26 '13 at 8:55
@luserdroog No this was the standard GUI based mail program under Irix – Anthon Apr 26 '13 at 9:00
@Anthon I'm not sure if it's still possible, but the possibility of using escape-codes to get a terminal to "repeat" text coming to it from the write command - thus executing commands/scripts as the user owning the terminal. It's supposedly the reason why many recommend turning off messages mesg -n for users most of the time, and for root always. AFAIK, this was actually done - though I don't know if it ever was exploited. So random text from a catted executable, could perhaps be executed. – Baard Kopperud Apr 26 '13 at 9:29

Most terminal emulators will send back some response, if they receive certain escape sequences (have a look at the xterm control sequences documentation). E.g., you can send \e[0c to a VT100-like emulator and it will send back the device attributes, something like \e[?1;2c (This is probably what Keith observed.) But these answers are not arbitrary strings. Still, having an executable named 2c somewhere on your system that does something fatal is a bad idea.

Update: The risks are in fact bigger than I thought, due to the possibility to set the title of an xterm window and to send back the title using appropriate escape sequences ( In contrast to the example above, the title can be an almost arbitrary string.

share|improve this answer
That's already cutting it very close. – Gunchars Apr 26 '13 at 7:32
There's an even older feature -- 'answerback message', sent in response to ENQ (C-e) character. On a real VT100, it is set by the user in the terminal's SETUP menu; maybe there are terminal emulators that allow setting it remotely... – sendmoreinfo May 2 '13 at 9:18

This changes the terminal title in GNOME Terminal 3.6.1, unless overridden by something like PS1:

printf "\033]2;Script Kiddie was here\007"

Now open a new GNOME Terminal window to test the cat version:

printf "\033]2;Script Kiddie was here\007" > test.bin
cat test.bin

Yep, this also sets the terminal title.

There used to be a security issue with an escape code resulting in the title being printed to the command line, so you could effectively create a file, which when cated would print (I'm not sure if you could put a newline in there) arbitrary commands. Ouch!

share|improve this answer

I have definitely experienced xterm inserting arbitrary characters into itself as if I had typed them. And on occasion this has apparently included newline character, so that I got ngwerm:0riu: command not found as a response. I see no reason why someone could not craft a file that would send specific, harmful commands. So yes, at least some terminals are susceptible to attacks with arbitrary impact.

share|improve this answer

While using cat might not result in code execution, escape codes will be processed so you could easily be misled into thinking the script is harmless when in fact it is malicious.

Here is an example command you can run which will create a "malicious" shell script:

echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' >
chmod a+x

When you inspect the file, it seems harmless enough:

$ cat
echo "Hello dear reader, I am just a harmless script, safe to run me!"

But should you actually run it...

$ ./ 
...doing something bad here...

The script works by including raw escape codes to move the cursor up a couple of lines, so the rest of the script is written over the top of the malicious code, hiding it.

Nearly any other program will reveal the script for what it is. Only programs that don't process the file content (like cat, more and less -r) will produce the misleading output.

Note that tail and head also produce the same misleading output. Using "less +F" is therefore safer than "tail -f".

share|improve this answer
This is quite problematic... You can see what's actually going on by running echo $(cat, cat | grep . --color=yes (Note: the --color=yes is what's showing the "malicious" code here) or the build-in cat -v – Charlie Apr 24 at 22:02
True or false, it’s an answer for a different question: how trustworthy is cat in displaying the file’s content. – Incnis Mrsi Sep 17 at 21:37
@IncnisMrsi: It's not really an answer for a different question. This answer warns that cat will show escape codes, and provides a simple example with only one type of escape code, but there are many others. When combined with certain terminals, these can remap keys, overwrite files and in theory, even execute commands. So once you realise the danger of displaying escape codes, you will understand that it can sometimes be unsafe to cat an arbitrary file, as the question asked! – Malvineous Sep 18 at 23:22

Well, a terminal emulator basically simply prints out the characters sent to it.

Anything besides simply printing a character on the current position, like setting a new position, changing color, changing title, etc., is done by escape sequences.

The set of supported escape sequences usually consists of well defined standards like ANSI, which does not define a way to start other processes. Although it would be possible to implement such a sequence, I am not aware of any terminal emulator intentionally allowing such things.

In theory a bug like a buffer overflow might be used to trigger arbitrary functionality. But this would be possible in pretty much any other binary, too.

share|improve this answer

In general there is usually no risk to catting an arbitrary file. My usual method for analyzing a file is to do the following:

$ file <mystery file>
$ strings <mystery file> | less

The above allows me to determine a file's type through the file command and the strings command allows me to dump any identifiable strings from would-be binary files that I"m not sure about their lineage.


file output
$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
strings output
$ strings /bin/ls|less
%b %e  %Y
%b %e %H:%M
Try `%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
share|improve this answer
running strings on an unknown file can also have problematic consequences.… – Jan Wikholm Oct 26 '14 at 10:43
@IncnisMrsi - read the first sentence!!!! – slm Sep 18 at 3:54
OK, retracting my previous statement, The answer is short, using confusing terminology, unfounded, and evidently incomplete. Note that in security, “arbitrary” ≠ random as distributed in your favourite OS. – Incnis Mrsi Sep 18 at 10:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.