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

Grant Taylor <[email protected]> Mon, 6 Mar 2023 23:46:35 -0700
Newsgroups sci.crypt,alt.security.pgp,alt.bbs,comp.terminals,alt.computer.security
Organization TNet Consulting
Message-ID <[email protected]>
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