Re: ? Unsafe terminal escape sequences and ANSI codes from decryption

Grant Taylor <[email protected]> Sun, 5 Mar 2023 09:59:19 -0700
Newsgroups sci.crypt,alt.security.pgp,alt.bbs,comp.terminals,alt.computer.security
Organization TNet Consulting
Message-ID <[email protected]>
On 3/5/23 2:19 AM, G.K. wrote:
> Is it unsafe to concatenate certain terminal escape sequences or ANSI 
> codes inside a terminal emulator?

I don't think that /concatenating/ terminal escape sequences in and of 
itself is unsafe.

That being said, it is possible to have carefully / mischievously 
crafted sequences that can appear to hide parts of the sequence and thus 
do undesirable things.

Consider the following:

    $ echo ; rm -rf /*; echo XXXXXXXXXXXXXXXXXXX the quick brown fox 
jumped over the lazy dogs

Where "X" is the escape sequence to move the cursor to the left.  Thus 
after pasting the sequence you see the following on the command line:

    $ echo the quick brown fox jumped over the lazy dogs

In this case the escape sequences are being used to hide multiple 
commands (rm and a 2nd echo).

> What could go wrong here?

Outputting raw content can easily mess up the sate of the terminal such 
that what's on the screen doesn't match what the system thinks is on the 
screen.

I've often seen such output end up ringing the bell (pc speaker beep) 
and / or invoke the sequence to cause the terminal (emulator) to send 
the answer back one or more times.  The answer back actually gets typed 
into the input on the new line, so sometimes you need to clear that.

It could be conceivable that there is data on the screen that you want 
to retain and don't have elsewhere and the escape sequences clear the 
screen and / or the scroll back buffer thereby causing you to loose the 
data on the screen.

> Is there potential for malicious escape sequences in the plaintext?

I don't consider the escape sequences themself to be malicious.  The use 
of them can be malicious.

It also depends on what you consider "plain text" to be.  As in what 
byte values are allowed.

Then there are files that claim to be plain text which aren't, either 
through corruption and / or malicious intention.

> Could such escape sequences or ANSI codes hijack the terminal and 
> somehow compromise the system? If so then how?

The escape sequences themselves probably don't have the capability to 
compromise the system.  However they can be used in combination with 
other commands that could be used to compromise something.  E.g. 
removing files or enabling a vulnerable service or other undesirable 
behavior.

> Where would I find timely information on such escape sequences and 
> mitigating any problems they could cause or safely filtering them?

The escape sequences themself aren't malicious.  Their use may be malicious.

Filtering the escape sequences is going to be a VERY DEEP rabbit hole. 
There are a LOT of escape sequences.

If you are truly worried about then, then use a less capable terminal 
(emulator) that simply doesn't honor all of the escape sequences.

> What tools are there to filter out such sequences to ensure safely 
> catting in a terminal? Are there any relevant tools in the GNU coreutils?

I occasionally look at unknown files with `cat -t` or `xxd` to see a 
safe representation of the text to see if there are undesirable use of 
escape sequences in them or not.

Remember, escape sequences themselves aren't malicious.  What is done 
with them may be malicious.

There is also some -- maybe closely -- related topic of copying and 
pasting content from the web into a terminal in that malicious actors 
have used CSS to hide undesirable commands in the middle of text that is 
being copied and pasted.  --  Again, the CSS itself isn't malicious. 
How it was used is malicious.

Tools -- escape sequences, CSS, knives, cars -- aren't malicious in and 
of themselves.  How people use them and what they do with them may be 
malicious.



-- 
Grant. . . .
unix || die