Busybox is an open source software project that provides implementations of various Unix tools. It has been around for a long time, and it’s used in a vast variety of projects, largely in embedded devices and in Linux distributions. More recently, Busybox grew in popularity for its use as a base layer for containers. The official Busybox Docker image has more than 10 million pulls.
The Busybox tools are called applets. With different compilation flags, users can customize applets and compile only applets relevant to their uses. In my research, I experimented with the more widespread applets, particularly with the Busybox shell.
The Busybox shell is an applet by itself. It is an implementation of the ash shell. After a while of looking into various features of the shell, I found a bug in its autocompletion feature. In short, I found out that when using autocompletion on a directory with files that have escape sequences in their name, the escape sequences would not be sanitized by the shell.
To understand this vulnerability, first we must understand what escape sequences are and why they pose a security threat.
The state of escape sequence vulnerabilities
An escape sequence (or control sequence) is a series of characters that changes the behavior of the terminal and allows interacting with it in some ways. Basic escape sequences are frequently used, such as sequences for formatting or color changing. However, some sequences that were commonly used in historical terminals are nowadays ignored by modern terminals, likely due to their abuse for malicious purposes.
By the early 2000s attacks using escape sequences were publicly disclosed and patched. Such terminal exploits I found from the past typically involved misusing a feature the terminal provided. One of the bold examples for such features is the screen dumping escape sequence, that commands the terminal to save the screen’s content to a specified file; and in some bad implementations allows overwriting any file(1). Another one is window title reporting, a sequence instructing the terminal to print it’s window’s title to the command line, which can be dangerous as another sequence allows changing the window’s title to any desired string.
Attackers made use of these features and others to exploit terminals in the past. Do not assume, however, that weaknesses in terminals involving such features are not being found to these days. One recent example is CVE-2015-8971, assigned for allowing title reporting in the Terminology terminal emulator.
Nevertheless, other vulnerabilities arise from specific implementation bugs in emulators. A quick search for such vulnerabilities yields numerous results in popular terminals like PuTTY, xterm, rxvt, the Apple terminal, gnome-terminal and others(2). In one mailing list discussion, Solar Designer addresses this issue and shows how he had easily reached memory corruptions and crashes in popular terminals. In his email he gives the example of CVE-2017-7467, a buffer overflow vulnerability in minicom that can be triggered with escape sequences. In a response to this email Michał Zalewski listed a number of similar vulnerabilities found by fuzzing terminal emulators. I expect to see more CVEs (or bug fixes) for vulnerabilities like these in the near future.
At any rate, I recommend reading this advisory from 2003 regarding terminal issues. It discusses the previously mentioned attacks and gives some more interesting examples, the worst being a vulnerability in some popular terminal emulators such as rxvt and xterm allowing an escape sequence to execute any command in given string(3). For additional reading refer to “A Blast from the Past” by Dejan Lukan.
I should probably stress that even without any vulnerability in a terminal emulator, escape sequences are still dangerous when printed unexpectedly. Legitimate escape sequences can clear the terminal, move the cursor or write invisible text. An attacker can make use of formatting to deceive an unsuspecting user or administrator and display false information.
Therefore, programs that run on the terminal should sanitize external content that may include escape sequences. Many vulnerabilities in programs had been reported for this issue alone. For example, Apache first had CVE-2003-0020 for not filter escape sequences in it’s error logs, later CVE-2003-0083 for the same issue with access logs, and more recently CVE-2013-1862 for logs written by mod_rewrite. The previous search also lists vulnerabilities in known programs, including nginx, wget, sshd and many others. To be fair, this simple search gives just a glimpse of this issue. Another example can be found in my previous post on RubyGems vulnerabilities, in which I explain CVE-2017-0899.
Busybox ash vulnerability explained
Busybox has code to check for escape sequences and replace them. To see it in action, I created files in a directory with escape sequences and ran ls on the directory. I wrote a short C code to create such files:
open(“\e[2J\e[1;1H\e[48;5;92;15mTwistlockLabs\e[0m”, O_RDWR | O_CREAT, S_IRUSR | S_IRGRP | S_IROTH);
I used escape sequences to clear the terminal and highlight my text. This is virtually harmless but it’s good enough for demonstration purposes. The output of ls was as desired – the bad characters were replaced with a question mark.
Yet as you probably guessed by now, when using the shell’s autocompletion feature, the filename was not sanitized. In other words, pressing tab on the directory with the bad file would print the escape characters.
This could put Busybox users at risk whenever they either use a shared filesystem, either locally by sharing physical setup or remotely shared directories, or otherwise when they download files or archives online. A malicious user could insert a file with a bad filename and exploit the vulnerability in the users’ terminals.
For instance, on a shared computer a user could simply create a bad file in his home directory, and when an administrator autocompletes this directory the user’s escape sequences payload would take effect.
While using an updated terminal emulator will protect users from known attacks using escape sequences, there are likely undiscovered vulnerabilities in emulators that attackers may exploit.
It should be noted that I used the default Docker configuration of Busybox, and compiling with any different set of flags may produce different results than those presented here.
Once I confirmed the bug I contacted Denys Vlasenko, the current Busybox maintainer. Denys promptly released a fix. However, despite my requests he did not release a version with the fix. Currently the only way to receive the update is by compiling the Busybox git master code. I will keep our Twitter page updated regarding this issue.
The vulnerability was assigned CVE-2017-16544 by MITRE.
On a different note, I’ve recently disclosed CVE-2017-15873 and CVE-2017-15874, which I found after fuzzing some Busybox applets. The first CVE is for a crash in Busybox’s bzip2 decompression algorithm, and the second CVE is for an integer underflow in it’s LZMA decompression algorithm. You can learn more about these vulnerabilities from their corresponding bug reports: Bug 10431 (CVE-2017-15873) and Bug 10436 (CVE-2017-15874).
- TERMINAL EMULATOR SECURITY ISSUES, https://marc.info/?l=bugtraq&m=104612710031920&q=p3
- In this search refer to vulnerabilities in terminal emulators such as rxvt or xterm
- This vulnerability never made it to an official release, hence the lack of a CVE ID
- Application Security
- Container Security
- Cloud Platform
- Container Platform
- Enterprise Security
- Press Releases
- Twistlock General
- Container Registry Scanning
- Runtime Security
- Security Innovations
- Linux Vulnerability
- Zero-Day Vulnerability
- Docker Security
- Open Source
- Customer Success
- Twistlock Partnership
- Vulnerability Management
- Twistlock Product
- Container Adoption
- Container Visibility
- Linux Security
- Google Cloud Platform
- Twistlock News
- Machine Learning
- Cloud Native
- shift left
- Twistlock Release Notes
- Security Alerts