[German]Security researchers from JFrog and Claroty Team82 have found 14 vulnerabilities in the popular BusyBox tool. All vulnerabilities were confidentially reported to the developer of BusyBox and fixed in version 1.34.0, which was released on August 19. The vulnerabilities could have been exploited for at least a Denial of Service (DoS) attack. However, in rarer cases, information leaks and possibly remote code execution would have been possible.
Advertising
What is BusyBox?
BusyBox is a computer program written in 1996 by Bruce Perens that combines several elementary standard Unix utilities. It runs on various POSIX environments such as Linux, Android or FreeBSD. However, many tools are designed to work with the interfaces of a Linux kernel. At the time, Bruce Perens wanted a Linux system that would fit on a single floppy disk, be complete and bootable, and could be used both as a rescue system and to install a Debian system. BusyBox was designed to work on embedded operating systems with very limited resources.
Some more background
Since many smart devices have to make do with limited memory and storage resources, they usually use a tool like BusyBox, which is marketed by Embedded Linux as a kind of "Swiss army knife". It is a software suite with many useful Unix utilities, called applets, packaged as a single executable file. BusyBox offers a full-fledged shell, a DHCP client/server, and also small utilities like cp, ls, grep, and others, and it also runs on many OT and IoT devices. It can also be found on popular programmable logic controllers (PLCs), human-machine interfaces (HMIs) and remote terminal units (RTUs).
Analyzing BusyBox for vulnerabilities
To investigate for vulnerabilities, a manual review of the BusyBox source code was first performed in a top-down approach (tracing user input to specific applet processing). This included looking for obvious vulnerabilities related to logical/memory corruption. The second approach was fuzzing. BusyBox was compiled using Asan and an AFL harness was implemented for each BusyBox applet. Each harness was then optimized by removing unnecessary parts of the code, running multiple fuzzing cycles on the same process (persistent mode), and running multiple fuzzing instances in parallel.
First, all daemon applets were subjected to fuzzing, including HTTP, Telnet, DNS, DHCP, NTP, and others. Many code changes were required to effectively fuzz network-based inputs. A few examples were prepared for each applet, and hundreds of fuzzed BusyBox instances were run over a few days. This generated tens of thousands of crashes that could be evaluated. To do this, security researchers developed an automated tool that classified all crash data based on the crash analysis report, which mainly included the stack trace, registers, and assembly code of the code area in question. Finally, an investigation of each crash took place, with minimized input vector, to understand the root causes, which allowed the creation of a proof-of-concept (PoC) exploiting the vulnerability responsible for the crash.
In summary, the following steps were taken in our research:
Advertising
1. Verification of the code
2. Fuzzing
3. Reduction & minimization
4. Triage
5. PoC
6. Testing multiple versions
7. Disclosure
Threat Landscape
For the open source security and cybersecurity communities, JFrog and Claroty have created a simple guide describing how to fuzz BusyBox. The guide is published along with all fuzzing harnesses, with the hope that these fuzzing logics can be further improved by the community to find and fix even more bugs in BusyBox in the future. Examining JFrog's firmware database of more than 10,000 embedded firmware, the security researchers found that 40 percent of them contained an executable version of BusyBox linked to one of the affected applets, showing that these problems are widespread among Linux-based embedded firmware.
However, the researchers conclude that these problems do not currently pose a critical security threat because:
- The DoS vulnerabilities are trivial to exploit, but the impact is usually mitigated by the fact that applets are almost always run as a separate forked process.
- The information leak vulnerability is not trivial to exploit.
- The use-after-free vulnerabilities may be exploitable for remote code execution, but currently no attempt has been made to develop an executable exploit for them. In addition, it is quite rare (and inherently insecure) to process an awk pattern from external input.
- Although the vulnerability was found in the LZMA decompression algorithm, many applets support LZMA compression. For example, the ubiquitous ZIP format supports LZMA compression as "type 14" compression.
From an attacker's perspective, ZIP is a much better attack vector because:
- unzip calls are much more common than direct unlzma calls.
- There are no file name restrictions with this attack vector (unlike the tar attack vector, which requires the .lzma file extension).
- The spied data can be extracted and stored in files that can later be read remotely.
Fixes and workarounds
All 14 vulnerabilities have been fixed in BusyBox 1.34.0 and users are urged to upgrade. If upgrading BusyBox is not possible (due to specific version compatibility requirements), BusyBox 1.33.1 and earlier versions can be compiled without the vulnerable features (applets) as a workaround. More information about the investigation can be found here.
