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

"G.K." <[email protected]> Mon, 6 Mar 2023 01:25:00 -0600
Newsgroups sci.crypt,alt.security.pgp,alt.bbs,comp.terminals,alt.computer.security
Organization Cyber23 news
Message-ID <[email protected]>
On 3/5/23 22:42, Richard wrote:
> [Please do not mail me a copy of your followup]
> 
> "G.K." <[email protected]> spake the secret code
> <[email protected]> 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.