I find these type of vulnerabilities very interesting.
I've also seen a sysop once using curl or wget in such a way that it would print out the response, while checking for an image file; it outputted all kinds of special characters.
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.
> 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.
> "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.
> 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.
Hi, I'm the author of the article. To stress your point, there really are so many embedded devices using Busybox, and most of them were never designed to be updated (or nobody cares enough to update them).
Also I never got to fuzzing networking applets (wget is the most obvious) but this is definitely something I plan to look into, if no one did that before, there are definitely vulnerabilities there too.
It could be good for me. We ($work) have some embedded devices running BusyBox that we only have limited (i.e. non-root) access to. I'm looking forward for a way to escalate privileges on these devices as a result of this!
It would be a stretch, but lets say you're driving some poorly thought out automation over a pty that has some sort of terminal emulator attached that has any sort of output-changeable answerback-like sequence.
The pty part is important because some software will assume you're running interactive if it sees that its STDIN/OUT is a pty, and change its functionality accordingly.
The vulnerability is that you can play tricks on interactive users' output. In general people (besides nerds) aren't shelling into these devices so it really doesn't seem like that big of a deal.
I've also seen a sysop once using curl or wget in such a way that it would print out the response, while checking for an image file; it outputted all kinds of special characters. 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.