Is it unsafe to concatenate certain terminal escape sequences or ANSI
codes inside a terminal emulator?

Here is the scenario. I am working from a terminal emulator (lxterm,
gnome-terminal, mate-terminal, guake, terminology). I decrypt a message
to a file. I cat the plaintext file to the terminal ('cat $filename' or
'less -r $filename').

What could go wrong here?

Is there potential for malicious escape sequences in the plaintext?
Could such escape sequences or ANSI codes hijack the terminal and
somehow compromise the system? If so then how?

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

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?

--

G.K.

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

[Please do not mail me a copy of your followup]

"G.K." <g@k.invalid> spake the secret code
<tu1ml1$ti6$1@news.cyber23.de> thusly:

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

For a hardware terminal it is doubtful. The most they could do is
request the contents of the screen be sent to the host or auxiliary
port and not every terminal supports sending screen contents back to
the host.

For a terminal *emulator* it's always possible that they could
identify a vulnerability in the ESC processing code that could lead to
a buffer overflow and the ability to inject bytes into the stack or
heap.

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

Software vulnerabilities in the emulator would have to be found by
analyzing the source code (or binary code) of the emulator. It's not
intrinsic to the ESC sequences themselves.

>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?

None AFAIK.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On 3/5/23 22:42, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "G.K." <g@k.invalid> spake the secret code
> <tu1ml1$ti6$1@news.cyber23.de> thusly:
>
>> Is there potential for malicious escape sequences in the plaintext?
>
> For a hardware terminal it is doubtful. The most they could do is
> request the contents of the screen be sent to the host or auxiliary
> port and not every terminal supports sending screen contents back to
> the host.
>
> For a terminal *emulator* it's always possible that they could
> identify a vulnerability in the ESC processing code that could lead to
> a buffer overflow and the ability to inject bytes into the stack or
> heap.
>
>> Where would I find timely information on such escape sequences and
>> mitigating any problems they could cause or safely filtering them?
>
> Software vulnerabilities in the emulator would have to be found by
> analyzing the source code (or binary code) of the emulator. It's not
> intrinsic to the ESC sequences themselves.
>
>> 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?
>
> None AFAIK.

It looks like I have been greeted by a terminal buff. This may be
fortuitous.

Another distinction occurs to me that might ease the problem
requirement. Is there a cheap way to distinguish between control codes
and formatting codes (color, foreground, background, underline,
blinkenlights) codes in a text stream.

What I mean by 'control codes' are codes for bell, repositioning cursor,
backspace and flush, etc. What I mean by 'formatting codes' is strictly
that which formats the color and appearance without any cursor movement
or flushing on the x and y of the display.

I think this simplifies my problem because it is really the control
codes I would want to watch out for, which could possibly trick someone
visually. That is of course barring some zero day hiding in the source
code of the terminal as you have said.

This would allow concatenating colorized text without stripping all the
color, and I think it would be _relatively_ safe. Some of the messages
being viewed this way would come from unknown persons. I would still
like to be able to view the color and background formatting without any
great risk of exploitation.

Perhaps there is a code that toggles arbitrary escapes off, that could
be injected into the stream, rather than truncating out of the stream.
although I haven't been able to find it.

--

G.K.

On 3/6/23 01:25, G.K. wrote:
> On 3/5/23 22:42, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> "G.K." <g@k.invalid> spake the secret code
>> <tu1ml1$ti6$1@news.cyber23.de> thusly:
>>
>>> Is there potential for malicious escape sequences in the plaintext?
>>
>> For a hardware terminal it is doubtful.  The most they could do is
>> request the contents of the screen be sent to the host or auxiliary
>> port and not every terminal supports sending screen contents back to
>> the host.
>>
>> For a terminal *emulator* it's always possible that they could
>> identify a vulnerability in the ESC processing code that could lead to
>> a buffer overflow and the ability to inject bytes into the stack or
>> heap.
>>
>>> Where would I find timely information on such escape sequences and
>>> mitigating any problems they could cause or safely filtering them?
>>
>> Software vulnerabilities in the emulator would have to be found by
>> analyzing the source code (or binary code) of the emulator.  It's not
>> intrinsic to the ESC sequences themselves.
>>
>>> 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?
>>
>> None AFAIK.
>
> It looks like I have been greeted by a terminal buff. This may be
> fortuitous.
>
> Another distinction occurs to me that might ease the problem
> requirement. Is there a cheap way to distinguish between control codes
> and formatting codes (color, foreground, background, underline,
> blinkenlights) codes in a text stream.
>
> What I mean by 'control codes' are codes for bell, repositioning cursor,
> backspace and flush, etc. What I mean by 'formatting codes' is strictly
> that which formats the color and appearance without any cursor movement
> or flushing on the x and y of the display.
>
> I think this simplifies my problem because it is really the control
> codes I would want to watch out for, which could possibly trick someone
> visually. That is of course barring some zero day hiding in the source
> code of the terminal as you have said.
>
> This would allow concatenating colorized text without stripping all the
> color, and I think it would be _relatively_ safe. Some of the messages
> being viewed this way would come from unknown persons. I would still
> like to be able to view the color and background formatting without any
> great risk of exploitation.
>
> Perhaps there is a code that toggles arbitrary escapes off, that could
> be injected into the stream, rather than truncating out of the stream.
> although I haven't been able to find it.

I just figured out that 'col' can filter out reverse chars. So now I am
poking around groff, troff, nroff to see if there is any magic hidden in
them.

--

G.K.

"G.K." <g@k.invalid> writes:
> Another distinction occurs to me that might ease the problem
> requirement. Is there a cheap way to distinguish between control codes
> and formatting codes (color, foreground, background, underline,
> blinkenlights) codes in a text stream.

'less -R' does something along those lines. I don't know if the
filtering code is conveniently separable from the rest of 'less', but
it might be a start: somebody else has already done the work of making a
set of decisions about which codes count in which category.
--
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, "<anakin@pobox.com>"))

On 3/6/23 03:29, Simon Tatham wrote:
> "G.K." <g@k.invalid> writes:
>> Another distinction occurs to me that might ease the problem
>> requirement. Is there a cheap way to distinguish between control codes
>> and formatting codes (color, foreground, background, underline,
>> blinkenlights) codes in a text stream.
>
> 'less -R' does something along those lines. I don't know if the
> filtering code is conveniently separable from the rest of 'less', but
> it might be a start: somebody else has already done the work of making a
> set of decisions about which codes count in which category.

This solves the problem. This is a boon and does almost all the work
necessary. From the less manual:

[quote]
-R or --RAW-CONTROL-CHARS
Like -r, but only ANSI "color" escape sequences are output in "raw"
form. Unlike -r, the screen appearance is maintained correctly in most
cases. ANSI "color" escape sequences are sequences of the form:

ESC [ ... m

where the "..." is zero or more color specification characters For the
purpose of keeping track of screen appearance, ANSI color escape
sequences are assumed to not move the cursor. [/quote]

After this I can pipe through a few intelligent line length and UTF-8
validation checks and ship it.

--

G.K.

[Please do not mail me a copy of your followup]

"G.K." <g@k.invalid> spake the secret code
<tu44aq$1o4r$1@news.cyber23.de> thusly:

>Another distinction occurs to me that might ease the problem
>requirement. Is there a cheap way to distinguish between control codes
>and formatting codes (color, foreground, background, underline,
>blinkenlights) codes in a text stream.

The ANSI sequences are described in ECMA-48:
<https://www.ecma-international.org/publications-and-standards/standards/ecma-48/>

Other terminals have their own code sequence, some of which are
documented here:
<https://terminals-wiki.org/wiki/index.php/Category:Code_Chart>. You
can also reverse engineer them from the terminfo/termcap database.
<https://invisible-island.net/ncurses/#download_database>

>What I mean by 'control codes' are codes for bell, repositioning cursor,
>backspace and flush, etc. What I mean by 'formatting codes' is strictly
>that which formats the color and appearance without any cursor movement
>or flushing on the x and y of the display.

For ANSI sequences, this is well defined. For other terminal types,
it depends on their control sequences which are usually documented in
the manual accompanying the terminal. There are a very few fancy
terminals which allowed you to download firmware directly into the
terminal which potentially means for arbitrary control sequences.
However, these terminals were not common (AFAIK) and are unlikely to
be targetted in random control sequence streams you'd encounter on the
net. It was not uncommon for OEM manufacturers to allow custom ROMs
to be installed in order to support custom control sequences.

If you want to understand the inner workings of how a hardware
terminal typically processes the incoming byte stream, I can point you
to more resources that explain it in detail.

>I think this simplifies my problem because it is really the control
>codes I would want to watch out for, which could possibly trick someone
>visually. That is of course barring some zero day hiding in the source
>code of the terminal as you have said.

Terminal *emulator*, not terminal.

>Perhaps there is a code that toggles arbitrary escapes off, that could
>be injected into the stream, rather than truncating out of the stream.
>although I haven't been able to find it.

There is no such thing for ANSI control sequences (look at the ECMA-48
link above) and in all the other oddball terminals I've looked at,
they don't have this either. There would be no point in having this
because the whole point of a smart terminal is for it to understand
and process commands in the communication stream.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

> For a hardware terminal it is doubtful. The most they could do is
> request the contents of the screen be sent to the host or auxiliary
> port and not every terminal supports sending screen contents back to
> the host.

Actually, one might be able to program an answerback sequence that e.g.
contained a hostile command, then triggered the terminal to send said
command. Depending on how the particular model implements screen
content send, it might be possible to inject malicious commands via that
path too.

There are other forms of objectionable behavior. In some environments,
causing the terminal to make a lot of noise, for example, could be an
issue. Send your real VT100 the sequence "ESC [ 1 4 5 q" in such a
place, and the enjoy the panic of figuring out how to stop it.

De

On 3/6/23 3:29 PM, Dennis Boone wrote:
> Actually, one might be able to program an answerback sequence that e.g.
> contained a hostile command, then triggered the terminal to send
> said command. Depending on how the particular model implements screen
> content send, it might be possible to inject malicious commands via
> that path too.

Please walk me through this hypothetical scenario.

My main holdup is that I thought configuring the answerback was purely
client side. Is there some terminal (emulator) that can be caused to
alter it's answerback setting via control codes sent to it by the remote
system?

I would have thought that a local user would maliciously configure their
terminal (emulator) to send a suspicious answerback if / when prompted.

> There are other forms of objectionable behavior. In some environments,
> causing the terminal to make a lot of noise, for example, could be
> an issue. Send your real VT100 the sequence "ESC [ 1 4 5 q" in such
> a place, and the enjoy the panic of figuring out how to stop it.

Especially with buffer on one end and / or the other end.

--
Grant. . . .
unix || die

> My main holdup is that I thought configuring the answerback was purely
> client side. Is there some terminal (emulator) that can be caused to
> alter it's answerback setting via control codes sent to it by the remote
> system?

I'm pretty sure I've seen terminals where you can set it remotely, but I
can't point to evidence off the top.

But that's just one scenario. Aggravating factors might include:

- Even if you can't load answerback, you might be able to load
programmable function keys, and then entice the user to press one.

- The emulation of VT100 or similar gives one of the most powerful
command sets.

De

On 3/6/23 5:35 PM, Dennis Boone wrote:
> I'm pretty sure I've seen terminals where you can set it remotely,
> but I can't point to evidence off the top.

ACK

> But that's just one scenario. Aggravating factors might include:
>
> - Even if you can't load answerback, you might be able to load
> programmable function keys, and then entice the user to press one.
>
> - The emulation of VT100 or similar gives one of the most powerful
> command sets.

Fair enough.

I think the other big thing that I'm struggling with is the fact that in
a nominally two party system, the host and the terminal (emulator), the
host would be making the terminal (emulator) attack the host. And
nominally be enticing the user of the terminal (emulator) to take action.

With this in mind, I'm not seeing the actual attack vector / scenario.

Could things be done, maybe. But what would it accomplish that the host
didn't already have?

--
Grant. . . .
unix || die

> I think the other big thing that I'm struggling with is the fact that in
> a nominally two party system, the host and the terminal (emulator), the
> host would be making the terminal (emulator) attack the host. And
> nominally be enticing the user of the terminal (emulator) to take action.

I'm envisioning something more like some non-host party injecting
hostile text and control sequences that the host ends up sending
to some legitimate user.

De

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/6/23 3:29 PM, Dennis Boone wrote:
>> Actually, one might be able to program an answerback sequence that e.g.
>> contained a hostile command, then triggered the terminal to send
>> said command. Depending on how the particular model implements screen
>> content send, it might be possible to inject malicious commands via
>> that path too.
>
>Please walk me through this hypothetical scenario.
>
>My main holdup is that I thought configuring the answerback was purely
>client side. Is there some terminal (emulator) that can be caused to
>alter it's answerback setting via control codes sent to it by the remote
>system?

The HP space helmet terminals (HP2626A, HP2645, etc) would do that. They
also would allow you to program a function key to send a sequence, then
send a code to make all following text black-on-black, and then send a
code to press that function key. Great fun in student labs with the
HP/3000.

There also was a thing on the CDC 721 terminal where you could send a
sequence to copy the scrollback buffer into a second screen memory,
so after the person cleared the terminal you could go back and see
their session text including the login password by going through menus
to display the buffer. A friend of mine used this to great effect
at the registration office when he was a student.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Please do not mail me a copy of your followup]

drb@ihatespam.msu.edu (Dennis Boone) spake the secret code
<WnqdnaEQAqGw9Jv5nZ2dnZfqn_adnZ2d@giganews.com> thusly:

> > For a hardware terminal it is doubtful. The most they could do is
> > request the contents of the screen be sent to the host or auxiliary
> > port and not every terminal supports sending screen contents back to
> > the host.
>
>Actually, one might be able to program an answerback sequence that e.g.
>contained a hostile command, then triggered the terminal to send said
>command.

Good point, but most real terminals don't have much space for the
answerback message. In the VT100 it's 20 characters. In the VT320
it is 30 characters. Enough to contain a whole command, but not
anything huge.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On 3/6/23 6:41 PM, Dennis Boone wrote:
> I'm envisioning something more like some non-host party injecting
> hostile text and control sequences that the host ends up sending to
> some legitimate user.

Hum.

If I'm understanding you correctly, say someone manages to post a
message to an echo -- I think that's the term I want -- that contains
hostile control sequences and the terminal user reads said message,
thereby causing their terminal (emulator) to interpret said hostile
control sequences.

I'm eliding how such hostile control sequences make it that point and
only focusing on an unwitting user accidentally causing the host to send
them.

--
Grant. . . .
unix || die

On 3/6/23 7:22 PM, Scott Dorsey wrote:
> The HP space helmet terminals (HP2626A, HP2645, etc) would do that.

Interesting. Thank you for sharing Scott. Today I learned something. :-)

> They also would allow you to program a function key to send a sequence,
> then send a code to make all following text black-on-black, and then
> send a code to press that function key. Great fun in student labs
> with the HP/3000.

Ya, I can see how re-programming a function key has some value. I don't
know if that's as security sensitive as something like the answer back.

Aside: I know, don't ever trust something that an end user provides for
a security decision. But I've heard of answerback being used as a
terminal identification (along with the port that it's connected to) and
such information influencing other aspects of the system.

Further aside: I use the answerback capability of my two primary
terminal emulators; XTerm and iTerm2, as a way to identify the client
that I'm on to the host. It's nice to have as I SSH through multiple
systems. I can tweak creature features like title bar updates and the
likes based on known client terminal emulators.

> There also was a thing on the CDC 721 terminal where you could send a
> sequence to copy the scrollback buffer into a second screen memory,
> so after the person cleared the terminal you could go back and see
> their session text including the login password by going through
> menus to display the buffer. A friend of mine used this to great
> effect at the registration office when he was a student.

Interesting.

It seems like both of these attacks could relatively easily be defended
against -- as long as you knew to do so -- in that you could re-program
the terminal to behave correctly /and/ to clear the second screen memory.

For a few minutes I thought you were going to suggest something to have
the terminal copy screen contents and feed it back to the host in a way
that didn't echo on the host.

--
Grant. . . .
unix || die

Simon Tatham <anakin@pobox.com> writes:
> "G.K." <g@k.invalid> writes:
>> Another distinction occurs to me that might ease the problem
>> requirement. Is there a cheap way to distinguish between control codes
>> and formatting codes (color, foreground, background, underline,
>> blinkenlights) codes in a text stream.
>
> 'less -R' does something along those lines. I don't know if the
> filtering code is conveniently separable from the rest of 'less', but
> it might be a start: somebody else has already done the work of making a
> set of decisions about which codes count in which category.

Anything the source thinks should be displayed in black on black should
not be trusted. Therefore you should prefer ``-r or --raw-control-chars''
to ``-R or --RAW-CONTROL-CHARS''.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/6/23 7:22 PM, Scott Dorsey wrote:
>
>> There also was a thing on the CDC 721 terminal where you could send a
>> sequence to copy the scrollback buffer into a second screen memory,
>> so after the person cleared the terminal you could go back and see
>> their session text including the login password by going through
>> menus to display the buffer. A friend of mine used this to great
>> effect at the registration office when he was a student.
>
>Interesting.
>
>It seems like both of these attacks could relatively easily be defended
>against -- as long as you knew to do so -- in that you could re-program
>the terminal to behave correctly /and/ to clear the second screen memory.

Yes. The CDC 721 attack required physical access to the terminal and it
required the terminal to remain powered on before the attacker got to it.
Which is typically easy in an open terminal cluster but could be defeated
by turning the terminal off after using it.

>For a few minutes I thought you were going to suggest something to have
>the terminal copy screen contents and feed it back to the host in a way
>that didn't echo on the host.

There might be a way to do that, I don't know. The HP terminals have so
many crazy modes for local forms management and multidrop connections and
so forth that there could be all kinds of hidden vulnerabilities in there.

ANSI terminals are so much more sane than some of the stuff we had out there.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-03-07 07:35, Grant Taylor wrote:
> On 3/6/23 6:41 PM, Dennis Boone wrote:
>> I'm envisioning something more like some non-host party injecting
>> hostile text and control sequences that the host ends up sending to
>> some legitimate user.
>
> Hum.
>
> If I'm understanding you correctly, say someone manages to post a
> message to an echo -- I think that's the term I want -- that contains
> hostile control sequences and the terminal user reads said message,
> thereby causing their terminal (emulator) to interpret said hostile
> control sequences.
>
> I'm eliding how such hostile control sequences make it that point and
> only focusing on an unwitting user accidentally causing the host to send
> them.
>
>
>

The OP provided a clear and traditional attack path: Entice the OP to
read a file by passing it to either cat, stdout of a communications
program like PGP, or a non-filtering viewer such as traditional "more"
or some implementations of "less -R". Ditto could be done over a
traditional teletype remote connection where the OP naively expects
a human typing messages from their end, or an honest service providing
messages such as "newswires" or weather updates.

Note that "less -R and less -r" are mostly useful for viewing files that
contain locally controlled and trusted escape sequences for things like
color highlighting or sequences of self-overwriting progress bars. Such
files would typically come from capturing stdout from some other locally
trusted program like git.

The easiest way to do safe filtering is to simply drop any bytes in the
ranges 0-31, 127-159 and 255 (decimal), as those are control character
on various ASCII-derived terminal character sets. If you are certain
the terminal is in UTF-8 or CESU-8 mode, instead apply similar filters
to the decoded UCS-4 codepoints, then reencode the allowed ones. More
sophisticated filtering could recognize the syntax pattern of ECMA-48
CSI sequences, noting the maximum number of parameters and characters
per parameter in such sequences.

The entire attack category used to be known as an "ANSI Bomb" in
reference to the MS-DOS escape sequence handler known as ANSI.SYS

I fondly remembering trusted DEC systems using these capabilities to
do things like animated login screens on actual DEC VT-xxx terminals.

P.S.

A Handy reference for popular codes is the Linux manual page
console_codes(4). The manpage viewer itself is a good example of
providing already trusted input to "less -r"

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded