[TheDong]

> Then, afer some magic character was printed, their terminal would start interpreting the rest of the output as commands. The commands were gibberish, nothing happened, but very dangerous nonetheless.

By commands, you probably mean "escape sequences", which are not the same as running executables and isn't very dangerous.

If a terminal actually executed commands based on data printed to stdout, that would be a very significant vulnerability. It seems far more likely that the gibberish you're talking about is the usual mess of escape sequences.

[wolfgang42]

> "escape sequences", which are not the same as running executables and isn't very dangerous.

Unless your terminal has support for something like setting the answerback string, in which case the escape sequence could set it and then send an ENQ immediately before ending, causing the answerback to be typed into a shell prompt and executed. (Escape sequences aren't always as innocent as you might expect.) I don't know if any modern terminal emulators support this, but I believe it's been a vector in the past.

Edit: The article mentions some alternative vectors, specifically the screen dumping escape sequence (potentially allowing overwriting arbitrary files) and window title reporting (which behaves similarly to the answerback exploit I mention above), and links to [1] which gives more details on such exploits.

[1]: https://www.proteansec.com/linux/blast-past-executing-code-t...

[flipp3r]

> If a terminal actually executed commands based on data printed to stdout, that would be a very significant vulnerability. It seems far more likely that the gibberish you're talking about is the usual mess of escape sequences.

Well, this is what happened. It was a few years ago on some IBM copy of Linux, don't know the exact system or shell. It was like Linux except most of the things you'd expect to exist on a Linux box were missing.