Is using 'echo' to display attacker-controlled data on the terminal dangerous?

Question

Imagine the following code:

ATTACKERDATA="$(cat attackerControlledFile.txt)"
echo "${ATTACKERDATA}"

An attacker can, through whatever arbitrary process, modify the contents of attackerControlledFile.txt to anything they desire. The content can be ASCII, UTF-8, Binary, etc. Anything is fine. The machine also assumes that it is infinitely fast, so even an extremely large file of multiple terrabytes would be read and printed immediately.

Is it possible for an attacker, regardless of how unlikely it would be, to exploit this somehow by modifying the content of attackerControlledFile.txt? "Somehow" refers to things like:

• This code only works in bash
• This code requires the output to be printed onto a specific terminal emulator
• Etc.

Everything else assumes a reasonably sane system. This means that answers such as "If echo is an attacker-controlled binary that's actually malware" does not count, as the existence of malware is not exactly "reasonably sane". Answers that would require a specific software or version of that software to be present do count, as long as that software was not made for the purpose of exploitation.

---

A similar question asks Is it possible to use the Linux “echo” command maliciously?, but the accepted answer is actually about a flaw in the design of a web application. Furthermore, it requires the attacker to be able to do redirects, which as far as I know, this construct cannot do.

Answer 1

Is it possible for an attacker, regardless of how unlikely it would be, to exploit this somehow by modifying the content of attackerControlledFile.txt? "Somehow" refers to things like:

This code requires the output to be printed onto a specific terminal emulator

In fact, yes. Old terminals like vt100 have the ability to use ANSI escape sequences to do special things, like execute commands. The following site below documents this ability using a simple echo, like you describe.

https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/

The article is in depth with specific exploit instructions, but the general idea can be summarized from this excerpt from the site:

Dangerous Escape Sequences Terminal emulators support multiple features as described below [8]:

• Screen Dumping: a screen dump escape sequence will open arbitrary file and write the current content of the terminal into the file. Some terminal emulators will not write to existing files, but only to new files, while others will simply overwrite the file with the new contents. An attacker might use this feature to create a new backdoor PHP file in the DocumentRoot of the web server, which can later be used to execute arbitrary commands.

• Window Title: an escape sequence exists for setting the window title, which will change the window title string. This feature can be used together with another escape sequence, which reads the current window title and prints it to the current command line. Since a carriage return character is prohibited in the window title, an attacker can store the command in a window title and print it to the current command line, but it would still require a user to press enter in order to execute it. There are techniques for making the command invisible, like setting the text color to the same color as the background, which increases the changes of user pressing the enter key.

• Command Execution: some terminal emulators could even allow execution of the command directly by using an escape sequence.

As pointed out in the comments, this particular exploit was fixed decades ago on modern terminal emulators. This just happened to be a simple example that a 30 second Google search revealed that nicely demonstrates the concept that there's still software at work that could be exploitable even in something as simple as displaying a file.

Theoretically, there could be other problems with modern terminal emulators (buffer overflows?) that might be exploitable.

Answer 2

If the output is going to a terminal, you have potentially lots of problems (regardless of how you print it, unless you strip special characters), as per other answers.

If the file can be gigantic, the attacker can make bash use a lot of RAM. Consider head -c 100000 instead of cat to set an upper limit of 100kB. Or head -c 10000 | cat -v (show non-printing characters as ^M or whatever; may break UTF-8 multi-byte characters).

If you want the data to potentially be giant, consider running that command directly (not inside a var=$() capture), with the output of cat connected to your stdout directly.

---

Since you have the data in shell variable, not being evaled inside double quotes, you're safe from some things.

e.g. command substitution won't work.

peter@volta:/tmp$ foo='$(touch bar)'
peter@volta:/tmp$ echo "${foo}"
$(touch bar)

---

An attacker can munge the output slightly by using the string -n, which echo will interpret as an option instead of literal data.

$ echo "-n"     # notice that this doesn't print a newline.
$ echo ""       # unlike a normal echo "" or echo with no args

$

But bash's builtin echo doesn't treat "-n foo" as an option; it's printed literally:

$ echo "-nabcd"
-nabcd

Since you expand the shell variable inside double quotes, there's no way for it to become multiple args for echo, like echo "-n" "leave the cursor at the end of this string"

Similarly -e isn't possible, and isn't a danger anyway because your file can already contain arbitrary binary data.

---

/bin/echo from GNU Coreutils supports a --version option, so if you're not using a shell builtin echo then an attacker could get your program to print software version info. If that output ends up in something attacker-visible, it discloses some info about the target system.

---

For these reasons, the recommendation for portably printing arbitrary data is:

printf "%s\n" "${ATTACKERDATA}"

Works on all POSIX shells, not subject to the system-specific vagaries of echo.

• https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819

• https://unix.stackexchange.com/questions/58310/difference-between-printf-and-echo-in-bash

But note this does nothing about terminal vulnerabilities, it's just a safe way to write any data literally without echo munging it.

And binary data still treats \0 (a zero byte) as a terminator in most shells, because bash internally uses C strings. The OS execve interface also uses C strings, but shell builtins allow shells to bypass that for echo / printf, so it is possible for e.g. zsh to echo / printf binary data containing zero bytes.

---

And BTW, in bash you don't actually need cat to read a file. Command substitution with a redirect gets bash to do the reading itself.

ATTACKERDATA="$(< attackerControlledFile.txt)"

But if you want any processing, like head -c and/or cat -v, you should use a real command.

Answer 3

Some terminals can echo back screen content as-if typed.

Thus you can possibly force "typing" and thus command execution with the right terminal commands. I have done this on physical DEC VT62-ts. but have not tried to do it with the VT-52 mode of X-term

this exploit is well known, and is probably the reason why finger -l username strips all control characters (except newline and tab) from ~username/.plan etc

so yes it's dangerous. to make it safe pipe it through less or col etc.

Answer 4

No, echo used in the example above is fine

Echo simply prints a string to the pipe stdout (default)

per: https://superuser.com/a/699500/527937

Pipes can't overflow. A pipe is just a buffer (a certain amount of memory, most likely 64KB on a current system) between a producer and a consumer. If the producer produces faster than the consumer consumes, the producer is blocked (that means, the program will sleep) until the consumer makes room in the buffer again by reading from it.

As a side note, if you have a large ammount of data in 1x line ... cat can hang and/or consume an enormous amount of system memory.

Answer 5

The attacker could perform a content-injection attack, especially if they know what the shell prompt looks like.

By including something in the file that looks like is output from some other part of the system they might be able to decieve the user and get them to take some action.