CHIMERA: Fuzzing P4 Network Infrastructure for Multi-Plane Bug Detection and Vulnerability Discovery

CHIMERA: Fuzzing P4 Network Infrastructure for Multi-Plane Bug Detection and Vulnerability Discovery

Speakers: Jiwon Kim, Purdue University; Dave (Jing) Tian, Georgetown University; Benjamin E. Ujcich, Georgetown University

Conference: IEEE S&P

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

Overview

This talk introduces Chimera, a novel fuzzing framework designed to uncover bugs and vulnerabilities within P4 network infrastructure. Presented by Jiwon Kim from Purdue University, with collaboration from Georgetown University, the research addresses critical shortcomings in existing testing methodologies for programmable networks. Traditional network testing tools often focus on either the data plane or the control plane in isolation, failing to account for the complex interdependencies that lead to multi-plane bugs. Chimera fundamentally shifts this paradigm by providing multi-plane inputs simultaneously and employing a sophisticated P4 concrete execution (P4CE) engine as a reliable bug oracle.

The significance of Chimera lies in its ability to effectively test the intricate stack of P4 infrastructure, which comprises various software layers from device implementations to controller core logic. By identifying and exploiting the limitations of prior work—such as reliance on manual validation or single-plane input generation—Chimera demonstrates a superior capability to detect subtle yet impactful vulnerabilities. The findings of this research, including the discovery of seven new bugs and the assignment of two Common Vulnerabilities and Exposures (CVEs), underscore the urgent need for comprehensive multi-plane testing in modern programmable networks. These vulnerabilities range from network-wide denial of service (DoS) attacks to the tampering of host information within the controller, highlighting the severe security implications of such undiscovered flaws.

Background

▶ Watch: Introduction to Chimera, SDN, and P4 language (0:00)

Traditional networking relies on hardware-intensive routers that integrate both data plane forwarding (handling packets) and control plane logic (determining paths). This architecture often leads to complex, vendor-specific implementations and rigid network behaviors. Software-Defined Networking (SDN) emerged to decouple these planes, centralizing control logic in a remote controller that manages forwarding devices, typically via the OpenFlow protocol. While SDN offered greater flexibility, OpenFlow itself is based on a fixed set of messages, limiting developers' ability to implement customized network features beyond standard RFCs.

To overcome these limitations, the network community developed the P4 language, a domain-specific language designed to define how packets are processed. A P4 program allows network developers to precisely specify packet parsing, matching, and action execution. This program is then compiled into two outputs: a protocol definition for controller-data plane communication and an executable for the programmable data plane switch. In an ideal scenario, the behavior of the P4 program should perfectly align with the behavior of the underlying P4 infrastructure (the controller and switch implementations). However, as the talk highlights, software bugs within either the controller or the switch can lead to discrepancies, where the infrastructure's actual behavior deviates from the P4 program's intended logic. This makes the P4 program an excellent criterion for detecting infrastructure bugs.

The complexity of P4 infrastructure further exacerbates this problem. A programmable switch, for instance, can involve layers such as device implementation, a switch operating system, and a server for P4 protocol messages. Similarly, a controller might include a P4 protocol client, a P4 driver, a core layer for managing P4 entities, and a P4 translator. Each of these layers, and their interactions, presents potential points of failure. The research team analyzed 41 bug reports across five open-source P4 projects, revealing that an overwhelming 83.3% of bugs were triggered by control plane inputs. Crucially, 20.8% of these bugs were caused by multi-plane inputs simultaneously, where interactions between data plane packets and control plane rules led to unexpected behavior. This statistical evidence directly informed Chimera's design, emphasizing the necessity of multi-plane testing.

Existing fuzzing tools for SDN and P4 infrastructure have significant limitations. They typically fall into two categories: data plane fuzzers (e.g., FP4), which mutate packets but use fixed control plane rules, and control plane fuzzers (e.g., Intender), which mutate control plane messages but use simplistic data plane traffic. These tools are inherently single-plane inputs, unable to explore the multi-plane attack surface. Furthermore, most existing P4 fuzzing tools rely on manual validation oracles. Testers must manually extend the P4 program with queries or assertions, a process that is non-trivial, time-consuming, prone to human error, and potentially incomplete. These limitations create a significant blind spot for detecting the complex, multi-plane bugs prevalent in P4 networks.

Key Findings

▶ Watch: Analysis of bug triggers, highlighting multi-plane inputs (4:00)

Chimera's primary contributions revolve around two innovative techniques designed to overcome the limitations of prior P4 testing methodologies. First, it introduces robust support for multi-plane testing through smart mutators tailored for both data plane packets and control plane rules. This addresses the critical need to generate inputs that reflect the interdependencies between network planes, enabling the discovery of bugs that single-plane fuzzers miss. Second, Chimera pioneers the use of P4 concrete execution (P4CE) as a scalable and accurate bug oracle, eliminating the need for labor-intensive manual validation or resource-intensive symbolic execution.

The efficacy of Chimera was demonstrated through its application to open-source P4 infrastructure, leading to the discovery of seven new bugs and the assignment of two CVEs. Among these findings, two bugs were specifically triggered by multi-plane inputs, confirming the hypothesis that such interactions are a fertile ground for vulnerabilities. Furthermore, five of the discovered bugs were detectable only by P4CE, highlighting its superiority over manual assertion-based methods. The impact of these vulnerabilities is significant, with one CVE enabling a network-wide denial of service (DoS) attack on the controller, and another allowing for the tampering of host information within the control plane.

Comparative evaluations against existing fuzzers, specifically FP4 (a data plane fuzzer) and Intender (a control plane fuzzer), showcased Chimera's superior performance. Chimera achieved the highest coverage in both the data plane and the control plane, indicating its ability to explore a broader range of program states and execution paths. More impressively, Chimera demonstrated an up to 3.5 times higher bug detection rate compared to these established tools. These findings unequivocally establish Chimera as a more effective and comprehensive solution for identifying vulnerabilities and bugs in complex P4 network infrastructures.

Technical Deep Dive

▶ Watch: Shortcomings of current P4 fuzzers: single-plane and manual oracles (6:00)

Chimera's effectiveness stems from its innovative approach to generating multi-plane inputs and its robust bug oracle. The core challenge in fuzzing P4 infrastructure with multi-plane inputs lies in the inherent interdependencies between data plane packets and control plane table entries. Randomly generated packets or rules are highly unlikely to align with a P4 program's defined parser paths or match-action pipelines, leading to early drops and poor code coverage. Chimera addresses this with two specialized smart mutators: Parser Aware Packet Mutation (PAPM) and Header Guided Rule Generation (HGRG).

Parser Aware Packet Mutation (PAPM) tackles the problem of generating valid input packets that the P4 program's parser will actually process. Instead of creating completely random packets, PAPM directly refers to the target P4 program's definition. It first randomly selects a valid parser path within the P4 program, such as one handling UDP traffic or In-band Network Telemetry (INT). Once a path is chosen, PAPM "reversely generates" valid packet header values that correspond to that path. For example, if a UDP path is chosen, PAPM will ensure the IPv4 protocol number is set to 17. This ensures that the generated packets are syntactically and semantically valid according to the P4 program's parsing logic, allowing them to traverse deeper into the pipeline and trigger more complex behaviors.

Complementing PAPM, Header Guided Rule Generation (HGRG) focuses on creating valid control plane table entries. Generating random values for match fields (like an IP source address) or arbitrary string names for match fields would also likely result in entries that don't match any incoming packets or don't align with the P4 program's pipeline definition. HGRG overcomes this by referring not only to the P4 program's definition but also to the given input packet headers (generated by PAPM). This allows HGRG to generate table entries that are both structurally valid for the P4 program and contextually relevant to the fuzzed packet. For instance, it can generate a rule that matches a specific IPv4 source address found in the fuzzed packet, ensuring that the packet will hit a relevant table entry and trigger an action. This intelligent generation of interdependent inputs is critical for exploring cross-plane interactions.

The second cornerstone of Chimera is its P4 Concrete Execution (P4CE) engine, which serves as its scalable and accurate bug oracle. Existing approaches often rely on symbolic execution for test oracle generation, which collects path conditions and uses satisfiability modulo theories (SMT) solvers (like Z3) to find inputs. While powerful, symbolic execution often struggles with scalability when applied to complex fuzzing scenarios due to its computational intensity. P4CE, in contrast, takes a more pragmatic approach. It reads an input packet and a set of table entries (generated by PAPM and HGRG) and then concretely executes each statement within the P4 program using these specific values. Through this execution, P4CE calculates an expected output packet and its associated metadata.

The power of P4CE as a bug oracle lies in its direct comparison mechanism. The fundamental principle is that the behavior defined by the P4 program should be identical to the actual behavior of the P4 infrastructure. By comparing the output packet calculated by P4CE (the expected behavior) with the actual output packet produced by the P4 infrastructure under test, Chimera can detect any discrepancy. These discrepancies—whether a dropped packet that should have been forwarded, a modified header field that should have remained unchanged, or an unexpected error—are flagged as potential bugs. This approach provides an automated, objective, and scalable method for identifying semantic bugs that would otherwise require painstaking manual inspection or complex assertion logic.

Demo / Proof of Concept

▶ Watch: Introducing Chimera's approach: multi-plane fuzzing and P4 execution oracle (6:45)

The talk effectively illustrates Chimera's capabilities through a compelling case study: the discovery of a CVE enabling a denial of service (DoS) attack on the popular ONOS controller. This demonstration highlights how Chimera's multi-plane testing, combined with its smart mutators and P4CE oracle, can uncover critical cross-plane vulnerabilities.

The attack scenario involves a malicious Host A that floods the network with invalid IPv4 packets. A critical piece of the P4 program's logic, labeled "Rule 1" in the demonstration, specifies that packets originating from Host A's IPv4 address should be sent to the controller (e.g., via a send_to_CPU action). This means that even invalid packets from Host A are intentionally directed towards the control plane.

The vulnerability manifests at the ONOS controller's core. While the programmable switch, being designed for high-performance packet processing, can efficiently handle and forward even invalid IPv4 packets according to its P4 program, the ONOS core reacts differently. Upon receiving these invalid packets, the controller core continuously prints error messages such as "unable to interpret inbound packet." This constant stream of errors consumes the controller's resources and disrupts its normal operation. Crucially, the error messages prevent these packets from being properly delivered to higher-level applications running on the controller. The result is a denial of service: legitimate network applications on the ONOS controller become unresponsive or unable to process valid traffic, even though the data plane itself might still be forwarding packets.

Chimera's methodology proved instrumental in uncovering this specific vulnerability:

• Multi-plane Testing: The bug is inherently cross-plane, involving the interaction between data plane packet processing (invalid IPv4 packets) and control plane application logic (ONOS core's error handling). Chimera's ability to mutate both packets and rules simultaneously was essential for triggering this interaction.
• Parser Aware Packet Mutation (PAPM): PAPM ensured that the generated packets, while invalid in their content (e.g., malformed headers), were still specific enough to the P4 program's parsing logic (e.g., an IPv4 header was present) to be processed by the switch and matched by Rule 1. This allowed the packets to reach the send_to_CPU action.
• Header Guided Rule Generation (HGRG): HGRG generated a valid rule for the P4 program that explicitly matched Host A's address as the IPv4 source and specified a valid action like send_to_CPU. This ensured that the malicious packets were correctly routed to the controller, as per the P4 program's definition.
• P4 Concrete Execution (P4CE): The P4CE oracle played a crucial role in detecting the erroneous behavior. The P4 program, when executed concretely, would expect these input packets to be successfully delivered to the controller and, subsequently, to the applications. However, the actual P4 infrastructure (the ONOS controller) failed to deliver the packets to applications due to the continuous error messages in its core. P4CE precisely identified this discrepancy between the expected and actual behavior, flagging the DoS vulnerability.

This case study vividly demonstrates how Chimera's integrated approach can uncover complex, real-world security flaws that traditional, single-plane, or manually-validated fuzzing techniques would likely miss.

Defensive Implications

▶ Watch: Chimera's smart mutators for generating valid packets and table entries (8:30)

The findings presented by Chimera have profound implications for network defenders, P4 developers, and infrastructure operators. The existence of multi-plane bugs and critical CVEs, such as the ONOS controller DoS, underscores the necessity of a proactive and comprehensive security posture for programmable networks.

Firstly, organizations deploying P4 infrastructure should integrate advanced fuzzing tools like Chimera into their development and quality assurance pipelines. Regular, automated multi-plane fuzz testing of P4 switches, controllers, and compilers is crucial to uncover latent vulnerabilities before they can be exploited in production. Relying solely on single-plane testing or manual validation is no longer sufficient given the demonstrated complexity of cross-plane interactions.

Secondly, specific attention must be paid to the interaction points between the data plane and the control plane. Any P4 program action that directs packets or metadata from the data plane to the controller (e.g., send_to_CPU, clone_to_cpu) represents a critical trust boundary. Controllers must implement robust and resilient input validation mechanisms for all incoming data, regardless of its source or initial processing by the data plane. The ONOS DoS vulnerability, for instance, highlights a failure to gracefully handle malformed packets that were explicitly forwarded by the P4 switch. This includes thorough parsing, sanitization, and error handling within the controller's core logic to prevent malformed data from triggering resource exhaustion or application failures.

Thirdly, network operators should enhance monitoring capabilities for their P4-enabled networks. Continuous logging and anomaly detection systems should be configured to specifically look for patterns indicative of resource exhaustion, repeated error messages (like "unable to interpret inbound packet"), or unexpected behavior in the controller's core. Such alerts could signal an ongoing DoS attack or other forms of exploitation stemming from multi-plane vulnerabilities.

Furthermore, P4 developers and architects should adopt a "security by design" mindset, anticipating potential discrepancies between the P4 program's intended behavior and the P4 infrastructure's actual execution. This could involve incorporating P4CE-like validation techniques during the development phase, ensuring that the infrastructure's implementation rigorously adheres to the P4 program's specification. By using the P4 program itself as the ground truth, developers can catch semantic bugs early.

Finally, staying updated with security advisories and promptly patching identified vulnerabilities (including the two CVEs discovered by Chimera) is paramount. The research demonstrates that even seemingly innocuous interactions can lead to severe security flaws, emphasizing the need for continuous vigilance and patching cycles.

Key Takeaways

• P4 network infrastructure is inherently complex, comprising multiple layers in both the data and control planes, making it highly susceptible to subtle bugs and vulnerabilities.
• Traditional fuzzing tools, which operate on single planes or rely on manual validation, are inadequate for discovering the critical "multi-plane" bugs that arise from complex interactions between data plane packets and control plane rules.
• Chimera introduces Parser Aware Packet Mutation (PAPM) and Header Guided Rule Generation (HGRG) as "smart mutators" that generate interdependent, valid, multi-plane inputs, significantly improving bug detection rates.
• The P4 Concrete Execution (P4CE) engine serves as a scalable and accurate bug oracle, automatically comparing the P4 program's expected behavior with the infrastructure's actual behavior, thus overcoming the limitations of manual assertions or resource-intensive symbolic execution.
• Chimera successfully discovered seven new bugs and two CVEs, including a critical denial of service (DoS) vulnerability in the ONOS controller, demonstrating its superior effectiveness (up to 3.5 times higher bug detection rate) compared to existing fuzzers.
• The P4 program itself can and should be utilized as a definitive criterion for validating the correct behavior of the underlying P4 infrastructure, serving as a powerful tool for automated bug detection.

About the Speaker(s)

The research behind Chimera was presented by Jiwon Kim from Purdue University. This work was a collaborative effort, also involving Dave (Jing) Tian and Benjamin E. Ujcich from Georgetown University. Their collective expertise in network security and programmable networks was instrumental in developing this innovative fuzzing framework for P4 infrastructure.