From Terminal Output to Arbitrary Remote Code Execution

submited by
Style Pass
2023-09-14 22:00:07

It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.

Little did they know, that almost half a century later, it will still be the defacto standard for all terminal emulators, essential to the workflow of anyone who programs professionally in any capacity.

Well, recall me saying in-band encoding? It means that when a program wants to relay a message to the terminal it embeds it in the output, and perhaps more importantly, when the terminal wants to relay a message to the program it embeds it in the input. Yes, the user input.

Attack plan is simple. A program prints non-sanitized, non-trusted content. The content will contain our exploit. The exploit will elicit a response that contains a shell command, and a linefeed. The program, that was not expecting any further input, will leave it waiting in stdin. After it finished executing, the shell will kick back in, at which point our command will be read and executed.

Now, you might be wondering… Is it really that simple? How come it isn’t abused routinely? Why would that be supported at all by any terminal? Did no one see it coming? Do I really not have anything better to do with my time? I will address almost all of these.

Leave a Comment