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

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." <[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.

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.