Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.crypt > #54847 > unrolled thread

? Unsafe terminal escape sequences and ANSI codes from decryption

Back to article view | Back to sci.crypt

Contents

  ? Unsafe terminal escape sequences and ANSI codes from decryption "G.K." <g@k.invalid> - 2023-03-05 03:19 -0600
    Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Grant Taylor <gtaylor@tnetconsulting.net> - 2023-03-05 09:59 -0700
    Re: ? Unsafe terminal escape sequences and ANSI codes from decryption legalize+jeeves@mail.xmission.com (Richard) - 2023-03-06 04:42 +0000
      Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Jan Panteltje <alien@comet.invalid> - 2023-03-06 06:25 +0000
      Re: ? Unsafe terminal escape sequences and ANSI codes from decryption "G.K." <g@k.invalid> - 2023-03-06 01:25 -0600
        Re: ? Unsafe terminal escape sequences and ANSI codes from decryption "G.K." <g@k.invalid> - 2023-03-06 01:31 -0600
        Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Simon Tatham <anakin@pobox.com> - 2023-03-06 09:29 +0000
          [solved] Unsafe terminal escape sequences and ANSI codes from decryption "G.K." <g@k.invalid> - 2023-03-06 04:04 -0600
          Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Phil Carmody <pc+usenet@asdf.org> - 2023-03-07 09:36 +0200
        Re: ? Unsafe terminal escape sequences and ANSI codes from decryption legalize+jeeves@mail.xmission.com (Richard) - 2023-03-06 18:36 +0000
      Re: ? Unsafe terminal escape sequences and ANSI codes from decryption drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-06 22:29 +0000
        Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Grant Taylor <gtaylor@tnetconsulting.net> - 2023-03-06 17:21 -0700
          Re: ? Unsafe terminal escape sequences and ANSI codes from decryption drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-07 00:35 +0000
            Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Grant Taylor <gtaylor@tnetconsulting.net> - 2023-03-06 18:19 -0700
              Re: ? Unsafe terminal escape sequences and ANSI codes from decryption drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-07 01:41 +0000
                Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Grant Taylor <gtaylor@tnetconsulting.net> - 2023-03-06 23:35 -0700
                  Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-03-17 14:23 +0100
          Re: ? Unsafe terminal escape sequences and ANSI codes from decryption kludge@panix.com (Scott Dorsey) - 2023-03-07 02:22 +0000
            Re: ? Unsafe terminal escape sequences and ANSI codes from decryption Grant Taylor <gtaylor@tnetconsulting.net> - 2023-03-06 23:46 -0700
              Re: ? Unsafe terminal escape sequences and ANSI codes from decryption kludge@panix.com (Scott Dorsey) - 2023-03-08 20:56 +0000
        Re: ? Unsafe terminal escape sequences and ANSI codes from decryption legalize+jeeves@mail.xmission.com (Richard) - 2023-03-07 05:37 +0000

Page 1 of 2  [1] 2  Next page →

#54847 — ? Unsafe terminal escape sequences and ANSI codes from decryption

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.

[toc] | [next] | [standalone]

#54848

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

[toc] | [prev] | [next] | [standalone]

#54860

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

[toc] | [prev] | [next] | [standalone]

#54861

On a sunny day (Mon, 6 Mar 2023 04:42:23 -0000 (UTC)) it happened
legalize+jeeves@mail.xmission.com (Richard) wrote in
<tu3qvf$n907$1@news.xmission.com>:

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

Maybe use hexedit
cat <whatever> > test
hexedit test

should show any funny things
And you can then use it to delete things.
Now use the cleaned file 'test'

hexedit is cool.
:-)

[toc] | [prev] | [next] | [standalone]

#54863

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.

[toc] | [prev] | [next] | [standalone]

#54865

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.

[toc] | [prev] | [next] | [standalone]

#54866

"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>"))

[toc] | [prev] | [next] | [standalone]

#54867 — [solved] Unsafe terminal escape sequences and ANSI codes from decryption

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.

[toc] | [prev] | [next] | [standalone]

#54894

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/

[toc] | [prev] | [next] | [standalone]

#54873

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

[toc] | [prev] | [next] | [standalone]

#54874

 > 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

[toc] | [prev] | [next] | [standalone]

#54878

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

[toc] | [prev] | [next] | [standalone]

#54879

 > 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

[toc] | [prev] | [next] | [standalone]

#54880

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

[toc] | [prev] | [next] | [standalone]

#54881

 > 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

[toc] | [prev] | [next] | [standalone]

#54891

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

[toc] | [prev] | [next] | [standalone]

#55140

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

[toc] | [prev] | [next] | [standalone]

#54882

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

[toc] | [prev] | [next] | [standalone]

#54892

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

[toc] | [prev] | [next] | [standalone]

#54911

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.crypt

csiph-web