Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing

Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing

Speakers: Asmita, Yaroslav Oliinyk, Michael Scott, Ryan Tsang

Conference: USENIX Security '24

YouTube: https://www.youtube.com/watch?v=amzgAEWqQ5s

Overview

This talk, presented by Asmita and her collaborators from NetRise, delves into novel approaches for enhancing the effectiveness of fuzzing in embedded systems, specifically targeting BusyBox. The research introduces two primary techniques: leveraging Large Language Models (LLMs) for initial seed generation and implementing a crash reuse methodology to identify vulnerabilities across different target variants. The core motivation stems from the pervasive use of BusyBox in Internet of Things (IoT) and eXtended IoT (X-IoT) devices, often running outdated and vulnerable versions.

The work highlights a critical security gap in the vast and expanding IoT ecosystem, where resource-constrained devices frequently incorporate complex software components like BusyBox without adequate security validation. By demonstrating how LLMs can significantly improve the discovery rate of crashes and how replaying known crash-inducing inputs can efficiently uncover vulnerabilities in related software versions, the researchers offer practical, advanced strategies for securing these ubiquitous devices. This research is particularly relevant to security practitioners, firmware developers, and supply chain security experts grappling with the challenges of embedded system security.

Background

▶ Watch: Introduction to Fuzzing BusyBox in IoT (0:00)

The proliferation of IoT devices across diverse industrial segments has transformed the technological landscape, simultaneously introducing a substantial increase in attack surfaces. Embedded systems form the bedrock of this ecosystem, with firmware serving as the primary logic. A common development practice involves integrating numerous third-party libraries and Software Development Kits (SDKs). Vulnerabilities within these external components can compromise the entire device ecosystem, making their security paramount.

The focus of this research is BusyBox, a highly versatile and widely adopted software suite in embedded Linux-based firmware. BusyBox is renowned for its lightweight nature and efficiency, consolidating over 300 common Linux utilities into a single, compact executable. This characteristic makes it ideal for resource-constrained embedded devices, ranging from routers and network appliances to industrial control systems. Given its widespread deployment, the security posture of BusyBox directly impacts a vast array of critical infrastructure and consumer devices.

Fuzzing has long been recognized as a powerful software testing technique, particularly effective at uncovering vulnerabilities by feeding programs with malformed or unexpected inputs. While traditionally applied to generic software, fuzzing has increasingly been adapted for embedded domains. However, traditional fuzzing often struggles with the initial seed generation phase, which can significantly impact its efficiency and coverage. This challenge, coupled with the black-box nature of many embedded firmwares (where source code is unavailable), motivated the exploration of more sophisticated fuzzing techniques.

The research was significantly influenced by the recent advancements in Large Language Models (LLMs). Known for their prowess in natural language processing and text generation, LLMs have permeated various domains. The researchers sought to experimentally investigate how these AI models could be leveraged to enhance fuzzing, specifically for generating high-quality initial seeds. This approach aimed to overcome the limitations of random seed generation, potentially leading to more effective vulnerability discovery.

A secondary, yet equally impactful, motivation emerged from the practical experience of fuzzing: crash reuse. The observation that a single crash-inducing input could potentially trigger similar vulnerabilities across different variants of a target software led to the development of this technique. Unlike traditional crash replay, which typically re-verifies crashes on the same target, crash reuse extends this concept to different versions, compilation optimizations, or even architectures of the target. This method offers a promising avenue for efficiently identifying known or similar vulnerabilities across an organization's diverse product portfolio without the need for extensive re-fuzzing from scratch. The authors cited prior work utilizing LLMs for fuzzing, such as ChatAFL, ChatFuzz, Fuzz4All, and WhiteFox, which targeted various inputs like protocols, programming languages, and compilers. They also drew inspiration from a blog post by Google's OSS-Fuzz team, which discussed integrating LLMs for automatic harness generation, further solidifying the potential of AI in fuzzing.

Key Findings

▶ Watch: Novel approach: Reusing crashes across target variants (3:00)

The research yielded several significant findings across its two primary techniques, highlighting both the prevalence of security issues in the embedded ecosystem and the effectiveness of the proposed methodologies:

1. Widespread Use of Outdated BusyBox Versions: A crucial discovery, made possible by access to real-world BusyBox ELF files from NetRise, revealed that many IoT products are still utilizing significantly older and often vulnerable versions of BusyBox. For instance, while the latest version during the experiments was 1.36.1, devices were found running versions as old as 1.7.2. This widespread adoption of legacy software creates a substantial attack surface and underscores a critical gap in software supply chain security for embedded devices.

1. LLM-Enhanced Seed Generation Improves Crash Discovery (Technique 1): The integration of LLMs, specifically OpenAI GPT-4, for generating initial fuzzing seeds demonstrated a substantial increase in the number of crashes compared to traditional fuzzing with randomly generated seeds. After using AFL triage to filter for unique crashes, the LLM-driven approach consistently showed better results across various BusyBox applets (e.g., awk, man, dc, ash) and versions. While the improvement in edge coverage was not always significant across all targets, the higher crash count provides more potential vulnerabilities for security analysts to investigate, making the fuzzing process more fruitful without introducing significant time overhead.

1. Efficient Vulnerability Discovery via Crash Reuse (Technique 2): The crash reuse technique proved to be highly effective for rapidly identifying known vulnerabilities across different BusyBox variants. By replaying a consolidated set of approximately 24,500 crash-inducing inputs collected from older BusyBox versions on a newer target (e.g., BusyBox 1.36.1), the researchers found a higher number of crashes in significantly less time compared to a 10-hour traditional fuzzing run on the new variant. This method successfully re-identified known Denial of Service (DoS) vulnerabilities related to memory exhaustion in Glibc components like regex and strftime within the newer BusyBox versions. This indicates that even updated BusyBox binaries might inherit vulnerabilities from their underlying libraries if not properly patched or configured.

1. Limitations and Practical Considerations: The research also candidly outlined the practical limitations of each technique. LLMs, while powerful, are not a "set-it-and-forget-it" solution; they require initial manual effort and verification to align their generated inputs with specific target requirements. Similarly, crash reuse is excellent for identifying known or similar vulnerabilities across variants but is not effective for discovering zero-day exploits. It serves as an invaluable initial phase to streamline vulnerability assessment, but comprehensive fuzzing remains necessary for novel bug discovery.

In summary, the key findings underscore the persistent security risks in the IoT landscape due to outdated software and present two innovative, complementary techniques that can significantly enhance the efficiency and effectiveness of embedded system security testing.

Technical Deep Dive

▶ Watch: Concerning discovery: Outdated BusyBox versions in IoT (7:00)

The research methodology was structured around two distinct, yet complementary, techniques designed to enhance fuzzing for BusyBox. The foundational element for both techniques involved BusyBox ELF files extracted from real-world IoT products, graciously provided by NetRise. This dataset was crucial as it represented the actual software deployed in devices, ranging in BusyBox versions from as old as 1.7.2 to the then-latest 1.36.1. This allowed for realistic vulnerability assessment and cross-version analysis.

The primary fuzzing tool employed was AFL++ (American Fuzzy Lop Plus Plus), configured in QEMU mode. This choice was strategic, as it enabled black-box fuzzing, meaning the approach did not require access to the target's source code. This is particularly vital for embedded systems where source code is often proprietary or unavailable, mimicking real-world firmware analysis scenarios. QEMU mode allows AFL++ to instrument and fuzz entire binaries, including those compiled for different architectures, making it suitable for diverse embedded targets.

Technique 1: LLM-Enhanced Initial Seed Generation

The first technique focused on improving the initial input corpus for fuzzers using Large Language Models (LLMs). The researchers utilized OpenAI GPT-4 for this purpose. The core idea was to generate more effective starting seeds, which could guide the fuzzer towards interesting execution paths and potential vulnerabilities more rapidly than purely random inputs.

The process involved:

1. Prompting the LLM: A simple, yet effective, prompt structure was used: "You are a fuzzer, you are initial seed generation for X applet fuzzer of the BusyBox and try provide the input seeds." Here, "X applet" would be replaced with specific BusyBox utilities like awk, man, dc, or ash.
2. Addressing LLM Knowledge Gaps: The researchers identified two scenarios for LLM input generation:

• Known Input Formats: If the target's input format was well-known and within the LLM's existing knowledge base, a direct prompt could yield decent results.
• Unknown Input Formats: For targets with obscure or proprietary input formats, fine-tuning the LLM would be necessary. This involves providing the LLM with example inputs and format specifications to tailor its generation capabilities, ensuring the seeds are syntactically valid and semantically meaningful for the target.

1. Fuzzing with LLM Seeds: The generated seeds were then fed as the initial corpus to AFL++ in QEMU mode.
2. Performance Metrics: The effectiveness of LLM-generated seeds was evaluated against traditional fuzzing using random initial seeds across several BusyBox versions and applets. Key metrics included:

• Number of Crashes: The raw count of detected crashes.
• Unique Crashes: To eliminate duplicates, AFL triage was employed, a tool that helps reduce and deduplicate crash-inducing inputs, providing a more accurate count of distinct vulnerabilities.
• Edge Coverage: A measure of how many unique code paths (edges in the control flow graph) the fuzzer managed to explore.
• Time Overhead: The impact on fuzzing speed (executions per second).

The experimental results demonstrated a substantial increase in the number of crashes with LLM-generated seeds, particularly in unique crashes after AFL triage. While edge coverage improvements were observed in some cases, they were not universally significant. Crucially, the inclusion of LLM-generated seeds did not introduce a significant time overhead, maintaining a similar execution rate per second. This suggests that LLM-assisted seed generation can enhance fuzzing efficiency without compromising performance.

Technique 2: Crash Reuse for Variant Analysis

The second technique, crash reuse, was developed as a strategic method for efficiently identifying vulnerabilities across different versions or configurations (variants) of a target, leveraging previously discovered crash-inducing inputs. This approach saves significant time by avoiding a full re-fuzzing campaign for each variant.

The steps involved:

1. Crash Collection from Technique 1: From the initial fuzzing campaigns (Technique 1) across various older BusyBox ELF files, a consolidated corpus of approximately 24,500 crash-inducing inputs was collected. These inputs represented specific conditions that led to crashes in the fuzzed BusyBox versions.
2. Target Variant Selection: A new variant of BusyBox was chosen as the target for replay, specifically the latest version available at the time, BusyBox 1.36.1.
3. Crash Replay: Instead of initiating a new fuzzing process, the collected crash-inducing inputs were simply replayed against the new BusyBox variant. The goal was to observe if these inputs, originally effective on older versions, would also trigger crashes in the updated software.
4. Comparative Analysis: The results from crash reuse were compared against a 10-hour traditional fuzzing run on the same new BusyBox variant (1.36.1) without any prior knowledge of crashes.

The findings were compelling: crash reuse led to a higher number of crashes in less time compared to the traditional fuzzing approach on the new variant. This technique successfully identified known Denial of Service (DoS) vulnerabilities stemming from memory exhaustion issues in underlying Glibc components, specifically within its regex and strftime functions. These were not new vulnerabilities but rather older CVEs that persisted in the newer BusyBox versions due to either unpatched Glibc instances or specific BusyBox configurations.

While highly efficient for identifying known vulnerabilities or similar issues across variants, the researchers acknowledged that crash reuse is not effective for finding zero-day vulnerabilities. Its primary strength lies in its ability to quickly assess if previously identified flaws exist in new deployments or updated versions, making it a valuable tool for initial vulnerability assessment and regression testing.

Demo / Proof of Concept

▶ Watch: Detailed fuzzing pipeline using AFL++ and LLMs (8:00)

While the talk did not feature a live, interactive demonstration of the fuzzing tools or a step-by-step exploit chain, the entire research itself served as a compelling proof of concept for the proposed methodologies. The "demonstration" was the empirical evidence presented through the experimental results, showing the efficacy of LLM-assisted seed generation and the crash reuse technique.

The researchers presented data illustrating the comparative performance:

• Graphs and tables showcasing the increased number of unique crashes when using LLM-generated seeds versus random seeds for specific BusyBox applets over 10-hour fuzzing periods. This visually demonstrated the LLM's ability to guide fuzzers more effectively.
• Quantitative results highlighting how the crash reuse technique on BusyBox 1.36.1 yielded more crashes in a shorter timeframe than a fresh, 10-hour traditional fuzzing campaign. This showcased the efficiency gain for identifying known vulnerabilities across variants.
• Specific examples of vulnerabilities re-discovered, such as DoS vulnerabilities related to memory exhaustion in Glibc's regex and strftime functions, which were older CVEs. This served as concrete evidence that the methods could uncover real-world security flaws.

Therefore, the "demo" aspect of this talk was the rigorous presentation of the experimental setup, the data collected, and the analytical comparison, all of which validated the practical applicability and benefits of their innovative fuzzing strategies for embedded systems. The paper and presentation collectively acted as a comprehensive demonstration of their findings and methodologies.

Defensive Implications

▶ Watch: Experimental results: LLM seeds yield more unique crashes (12:00)

The findings from this research carry significant implications for defenders responsible for the security of IoT and embedded devices, offering actionable insights to bolster their defenses against pervasive threats.

1. Prioritize Software Updates and Patch Management: The most critical defensive implication stems from the discovery that a substantial number of real-world IoT products are still running severely outdated and vulnerable versions of BusyBox (e.g., 1.7.2 when 1.36.1 is current). Defenders must implement robust patch management strategies for embedded systems, ensuring that all components, especially foundational ones like BusyBox and its underlying libraries (e.g., Glibc), are kept up-to-date. This requires vigilant monitoring of CVEs and vendor-supplied updates for firmware.

1. Adopt Advanced Fuzzing in the SDLC: Security teams should integrate advanced fuzzing techniques, similar to those presented, into their Software Development Life Cycle (SDLC) for embedded firmware. Leveraging LLM-assisted seed generation can significantly improve the efficacy of fuzzing campaigns, leading to the discovery of more crashes and potential vulnerabilities earlier in the development process. This proactive approach reduces the likelihood of shipping vulnerable products.

1. Implement Black-Box Fuzzing for Firmware: Given that source code is often unavailable for third-party or legacy embedded components, the use of AFL++ in QEMU mode demonstrates the effectiveness of black-box fuzzing. Defenders should invest in tools and expertise to perform such analysis, allowing them to assess the security of closed-source firmware components that are critical to their device's operation.

1. Leverage Crash Reuse for Efficient Regression Testing and Variant Analysis: The crash reuse technique offers a powerful tool for regression testing and assessing the security posture across different product variants or updated firmware versions. Instead of re-fuzzing from scratch, defenders can maintain a corpus of known crash-inducing inputs and quickly replay them against new builds or devices. This is particularly useful for:

• Rapid Assessment: Quickly identifying if known vulnerabilities have been re-introduced or persist in new firmware releases.
• Supply Chain Risk Assessment: Evaluating if different hardware platforms or software configurations using the same BusyBox base share known vulnerabilities.
• Cost-Effective Security Audits: Reducing the time and computational resources required for initial vulnerability assessments.

1. Strengthen Software Supply Chain Security: The re-discovery of older DoS vulnerabilities in Glibc within newer BusyBox versions highlights the cascading risk from third-party libraries. Defenders must scrutinize the entire software supply chain for their embedded devices, ensuring that all dependencies are patched and secure. This includes understanding the specific versions of libraries compiled into BusyBox and other firmware components. Tools for Software Bill of Materials (SBOM) generation and analysis can aid in tracking these dependencies.

1. Invest in Automated Triage and Analysis: The use of AFL triage to deduplicate crashes underscores the importance of automated crash analysis. Defenders should integrate tools that can automatically process and categorize crash reports, helping to distinguish unique vulnerabilities from duplicates and prioritize remediation efforts.

By adopting these defensive strategies, organizations can significantly enhance the security posture of their IoT and embedded devices, moving beyond reactive patching to a more proactive and intelligent approach to vulnerability discovery and management.

Key Takeaways

• Outdated Software Poses Significant Risk: A substantial number of real-world IoT devices run significantly older and vulnerable versions of BusyBox, creating a vast and exploitable attack surface.
• LLMs Enhance Fuzzing Effectiveness: Leveraging Large Language Models (LLMs) like OpenAI GPT-4 for initial seed generation can substantially increase the number of unique crashes discovered during fuzzing, improving the efficiency of vulnerability discovery without significant time overhead.
• Crash Reuse Streamlines Vulnerability Assessment: Replaying known crash-inducing inputs on different variants of a target (e.g., newer BusyBox versions) is an efficient method to quickly identify previously discovered or similar vulnerabilities, saving time compared to full re-fuzzing.
• Black-Box Fuzzing is Crucial for Embedded Systems: Utilizing tools like AFL++ in QEMU mode allows for effective black-box fuzzing of embedded firmware, which is essential when source code is unavailable.
• Underlying Library Vulnerabilities Persist: Even updated versions of core components like BusyBox can still contain older, unpatched vulnerabilities inherited from underlying libraries such as Glibc (e.g., DoS in regex and strftime).
• Hybrid Approaches Offer Best Results: While LLMs and crash reuse significantly improve aspects of fuzzing, they require initial manual effort and are best complemented with traditional fuzzing for comprehensive zero-day discovery.

About the Speaker(s)

The research presented was a collaborative effort. The talk was delivered by Asmita, who was the primary presenter. Her collaborators on this paper included Yaroslav Oliinyk, Michael Scott, and Ryan Tsang. This work was conducted in collaboration with NetRise, a company specializing in software supply chain security and X-IoT device security. NetRise played a crucial role by providing essential resources and support for the research, including access to real-world BusyBox ELF files extracted from various IoT products, which formed the foundation of the experimental dataset.