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