Live data from Hacker News

CVE-2017-16544: A Busybox autocompletion vulnerability

twistlock.com

11–15 of 15 posts

Re: CVE-2017-16544: A Busybox autocompletion vulnerability

#11
post #8
post #2

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…

> 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…

> "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...

Re: CVE-2017-16544: A Busybox autocompletion vulnerability

#12
post #8
post #2

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…

> 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…

> 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.

Re: CVE-2017-16544: A Busybox autocompletion vulnerability

#13
post #10
post #5

Earlier quoted context omitted.

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!

How do you get privilege escalation from shell escape sequences?

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.

Re: CVE-2017-16544: A Busybox autocompletion vulnerability

#14
post #10
post #5

Earlier quoted context omitted.

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!

How do you get privilege escalation from shell escape sequences?

Crazier shit has happened. In my case, pretty much everything on these devices runs as root so it may very well be possible.

Re: CVE-2017-16544: A Busybox autocompletion vulnerability

#15
post #9
post #3

This is quite ungood considering how many devices (read: routers, IoT) have busybox (or some zombie-like corpse of it) installed on them.

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 quite often shell into such devices. I think just playing tricks is a start and can easily escalate into something more serious.

Alpine also uses Busybox by default (IIRC) and people will use that definitely so it's definitely a problem.

Busybox is not only used in embedded devices.

Post reply on HN