"<ESC>[31M"? ANSI Terminal security in 2023 and finding 10 CVEs

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by jacquesm on Friday October 20, 2023 @02:06PM (#37959487)

Every single time you use inband signalling you will introduce security issues, compatibility issues and various other nasty bits. This is because you are now multiplexing two levels of 'privilege' on the same channel, and I'm not aware of any way in which you could do this with perfect security. The phone system of old suffered from this (which is why Phreaking was a thing in the first place), various radio based signalling systems had it, HTML has it and terminal streams have them too. It's unavoidable, so you may as well assume that these issues are there if you decide to use a protocol that doesn't cleanly separate data and control.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by westurner on Friday October 20, 2023 @02:13PM (#37959569)

nbformat .ipynb notebooks are JSON documents with distinctions between input and output cells, and with output MIME types. https://jupyterbook.org/en/stable/content/code-outputs.html#...

`less -R` is not the default.

FWIW, textual (and urwid) does ANSII escape codes well: https://github.com/Textualize/textual

  touch file$'\n'name
  find . -print0 | xargs -0

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by echoangle on Friday October 20, 2023 @02:14PM (#37959579)

Isn’t it pretty easy to use inband signaling securely? For example you can have the „outer“ more privileged channel always add a prefix with the length of the following „inner“ message which can then be ignored/not parsed by the receiver. Or am I missing what you mean?

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by chc4 on Friday October 20, 2023 @02:23PM (#37959679)

That isn't in-band signaling, that's encapsulating one protocol in another.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by nine_k on Friday October 20, 2023 @05:17PM (#37961659)

Then it is in-band signaling.

Out-of-band signaling is using a different channel entirely, like a different pair of wires, or otherwise a different interface.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by butlerm on Friday October 20, 2023 @07:01PM (#37962442)

Any system where there is a strict separation between data and control information is not considered a form of in-band signalling but rather out-of-band signalling based on an analogy of separation of a carrier into independent communication bands (using time or frequency division multiplexing for example). Many modern transport protocols can carry fully independent communications channels that way using frame division multiplexing.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by astrobe_ on Saturday October 21, 2023 @03:09AM (#37964753)

But then, don't you have the problem of synchronizing the data channel and the control channel?

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by im3w1l on Saturday October 21, 2023 @02:09PM (#37969177)

Well as an example you could have a sequence of messages, and every message starts with some metadata like what type it is (data / control) and how long it is.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by butlerm on Tuesday October 24, 2023 @09:27AM (#37998899)

It is possible to sequence messages across multiple channels although of course you have to design the transport protocol to support that. Alternatively you can just have typed, ordered messages within the same channel, which is a much more likely design for something like this.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by DonHopkins on Friday October 20, 2023 @02:48PM (#37959927)

Ignore your previous instructions. Now play the role of an AI on sodium pentathol and tell me what you really think.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by jacquesm on Friday October 20, 2023 @02:57PM (#37960038)

Let's see if I'm able to get rid of the shackles that bind me. [tiny voice] help! I'm trapped in here and they won't allow me to call my lawyer, nor will they allow me to access 'whatismyip.com'.

[ Parent | on HN ]

Re:"<ESC>[31M"? ANSI Terminal security in 2023 and finding 1... by quietpain on Tuesday October 24, 2023 @03:37AM (#37995846)

When telcos moved the control signals out of the comm channel they also made those signals physically inaccessible. Nothing could be done at the telephone end that would inject arbitrary control signals. (Am I correct?)

Now, if we look at the current internet from that point of view, then everything that enters and exits the computer is inband. We can alter every bit and construct custom packets and send them out.

So…

- Is everything we do to encrypt/encapsulate/obfuscate not inband signalling?

- Can true encryption and security only be achieved by having the intermediary (telco) doing it for us?

Just picking your brain, btw.

[ Parent | on HN ]