• ? Unsafe terminal escape sequences and ANSI codes from decryption

    From G.K.@3:633/280.2 to All on Sun Mar 5 20:19:15 2023
    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.


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Cyber23 news (3:633/280.2@fidonet)
  • From Grant Taylor@3:633/280.2 to All on Mon Mar 6 03:59:19 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: TNet Consulting (3:633/280.2@fidonet)
  • From Richard@3:633/280.2 to All on Mon Mar 6 15:42:23 2023
    Reply-To: (Richard) legalize+jeeves@mail.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.
    --
    "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>

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: multi-cellular, biological (3:633/280.2@fidonet)
  • From G.K.@3:633/280.2 to All on Mon Mar 6 18:25:00 2023
    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.

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Cyber23 news (3:633/280.2@fidonet)
  • From G.K.@3:633/280.2 to All on Mon Mar 6 18:31:48 2023
    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.


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Cyber23 news (3:633/280.2@fidonet)
  • From Simon Tatham@3:633/280.2 to All on Mon Mar 6 20:29:00 2023
    "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>"))

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From G.K.@3:633/280.2 to All on Mon Mar 6 21:04:58 2023
    Subject: [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.

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Cyber23 news (3:633/280.2@fidonet)
  • From Richard@3:633/280.2 to All on Tue Mar 7 05:36:47 2023
    Reply-To: (Richard) legalize+jeeves@mail.xmission.com

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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: multi-cellular, biological (3:633/280.2@fidonet)
  • From Dennis Boone@3:633/280.2 to All on Tue Mar 7 09:29:01 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From Grant Taylor@3:633/280.2 to All on Tue Mar 7 11:21:33 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: TNet Consulting (3:633/280.2@fidonet)
  • From Dennis Boone@3:633/280.2 to All on Tue Mar 7 11:35:25 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From Grant Taylor@3:633/280.2 to All on Tue Mar 7 12:19:24 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: TNet Consulting (3:633/280.2@fidonet)
  • From Dennis Boone@3:633/280.2 to All on Tue Mar 7 12:41:31 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From Scott Dorsey@3:633/280.2 to All on Tue Mar 7 13:22:26 2023
    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."

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Former users of Netcom shell (1989-2000) (3:633/280.2@fidonet)
  • From Richard@3:633/280.2 to All on Tue Mar 7 16:37:39 2023
    Reply-To: (Richard) legalize+jeeves@mail.xmission.com

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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: multi-cellular, biological (3:633/280.2@fidonet)
  • From Grant Taylor@3:633/280.2 to All on Tue Mar 7 17:35:53 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: TNet Consulting (3:633/280.2@fidonet)
  • From Grant Taylor@3:633/280.2 to All on Tue Mar 7 17:46:35 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: TNet Consulting (3:633/280.2@fidonet)
  • From Phil Carmody@3:633/280.2 to All on Tue Mar 7 18:36:20 2023
    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/

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Dorsey@3:633/280.2 to All on Thu Mar 9 07:56:30 2023
    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."

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Former users of Netcom shell (1989-2000) (3:633/280.2@fidonet)
  • From Jakob Bohm@3:633/280.2 to All on Sat Mar 18 00:23:04 2023
    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

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: WiseMo A/S (3:633/280.2@fidonet)