Claroty and JFrog discover 14 vulnerabilities in Busybox

Team82 and JFrog have announced the discovery, by using static and dynamic techniques, of 14 vulnerabilities affecting the latest version of BusyBox.

Typically found in embedded devices with limited memory and storage resources, BusyBox is marketed as the Swiss Army Knife of embedded Linux. It's a software suite of useful Unix utilities, known as applets, packaged as a single executable file.

Busybox can be found on many OT and IoT devices, including popular programmable logic controllers (PLCs), human-machine interfaces (HMIs), and remote terminal units (RTUs) - many of which now run on Linux.

As part of a commitment to improving open source software security, Claroty's Team82 and JFrog collaborated on a vulnerability research project examining BusyBox.

To research BusyBox, they used static and dynamic analysis approaches. First, a manual review of the BusyBox source code was conducted in a top-down approach (following user input up to specific applet handling). They also looked for obvious logical or memory corruption vulnerabilities.

The next approach was fuzzing. They compiled BusyBox with ASan and implemented an AFL harness for each BusyBox applet. Each harness was subsequently optimised by removing unnecessary parts of the code, running multiple fuzzing cycles on the same process (persistent mode), and running multiple fuzzed instances in parallel.

Details of the vulnerabilities

According to the collaboration, since the affected applets are not daemons, each vulnerability can only be exploited if the vulnerable applet is fed with untrusted data - usually through a command-line argument.

Specifically, these are the conditions that must occur for each vulnerability to be triggered:

CVE-2021-42373

•  Applies if the attacker can control all parameters passed to man.
•  man is built by the default BusyBox configuration but not shipped with Ubuntu's default BusyBox binary.

CVE-2021-42374:

• Applies if the attacker can supply a crafted compressed file that will be decompressed by using unlzma.
• Note that even if the unlzma applet is not available, but CONFIG_FEATURE_SEAMLESS_LZMA (enabled by default) is enabled, other applets such as tar, unzip, rpm, dpkg, lzma and man can also reach the vulnerable code when handling a file with the .lzma filename suffix.
• unlzma is built by the default BusyBox configuration and shipped with Ubuntu's default BusyBox binary.

CVE-2021-42375:

•  Applies if the attacker can supply a command-line to ash that contains the special characters $, {, }, or #.
•  ash is built by the default BusyBox configuration and shipped with Ubuntu's default BusyBox binary.

CVE-2021-42376:

•  Applies if the attacker can supply a command-line to hush that contains the special character \x03 (delimiter).
•  hush is built by the default BusyBox configuration but not shipped with Ubuntu's default BusyBox binary.

CVE-2021-42377:

•  Applies if the attacker can supply a command-line to hush that contains the special character -.

CVE-2021-42378, CVE-2021-42386:

•  Applies if the attacker can supply an arbitrary pattern to awk (the pattern is the first positional argument this applet takes).
•  awk is built by the default BusyBox configuration and shipped with Ubuntu's default BusyBox binary.

"We started from fuzzing all the daemon applets, including HTTP, Telnet, DNS, DHCP, NTP etc. Many code changes were required in order to effectively fuzz network-based input," the companies explain.

"For example, the main modification we performed was to replace all recv functions with input from STDIN to support fuzzed inputs. Similar changes were done when we fuzzed non-server applets as well."

Claroty's Team82 and JFrog prepared a couple of examples for each applet and ran hundreds of fuzzed BusyBox instances for a few days.

"This gave us tens of thousands of crashes to evaluate. We had to create classes of crashes with the same root cause to help reduce the volume of crashes we had in our sample set. Later, we minimised each group representative to work with a small subset of unique crash inputs," they say.

To fulfil these tasks, the team developed automatic tooling that digested all crash data and classified it based on the crash analysis report, which mainly includes the crash stack trace, registers, and assembly code of the relevant code area. For example, they merged cases with similar crash stack traces because they usually had the same problematic root cause.

Finally, the team researched each unique crash and minimised its input vector in order to understand the root cause, which allowed them to create a proof-of-concept that exploits the vulnerability responsible for the crash. In addition, they tested their PoCs against several BusyBox versions to understand when the bugs were introduced to the source code.

Threat Analysis and mitigation advice

To assess the threat level posed by these vulnerabilities, Team82 and JFrog inspected JFrog's database of more than 10,000 embedded firmware images. The team found that 40% of them contained a BusyBox executable file that is linked with one of the affected applets, making these issues extremely widespread among Linux-based embedded firmware.

According to Claroty, all 14 vulnerabilities have been fixed in BusyBox 1.34.0 and users are urged to upgrade immediately.