Nozomi Networks Labs uncovered a total of 37 vulnerabilities in the libfluid_msg library, a core component of the libfluid OpenFlow library that is used to process OpenFlow network packets. Notably, libfluid was selected in 2013 as the winner of the OpenFlow Driver Competition sponsored by the Open Networking Foundation (ONF).
These vulnerabilities could have significant impacts on network infrastructure since they can be exploited simply by sending a malformed OpenFlow network packet, potentially affecting any network component utilizing this vulnerable library. We are currently not capable of measuring how widespread the usage of this library is, nor all products that might be affected by these vulnerabilities. However, after finding it in use in a new SDN network appliance of a popular vendor in the IT/OT market, it is likely that other vendors are affected. For this reason, we hope that our research will raise awareness among vendors to mitigate these vulnerabilities in their OpenFlow products. Below, we share more information on the OpenFlow protocol, the libfluid framework, and the research process Nozomi Networks followed to identify and disclose these vulnerabilities.
Why it matters:
- High impact on SDN networks: The libfluid_msg library is integral to building and parsing OpenFlow messages in SDN (Software-Defined Networking) environments that use the libfluid framework. Vulnerabilities in this library can compromise the core functionality of OpenFlow network nodes (e.g., controllers and forwarders).
- Potential exploits: An attacker could easily exploit these vulnerabilities to crash SDN network applications that rely on the libfluid_msg library to parse OpenFlow protocol messages, leading to Denial-of-Service (DoS) attacks
What should I do?
Despite notifying the Open Networking Foundation, no official patches have been released. Thus, we recommend that vendors using this library in their OpenFlow products take the following proactive measures to mitigate potential risks:
- Locate and fix the bugs in the libfluid_msg library on their own.
- Implement network access controls to segregate access. Ensure the OpenFlow node using the vulnerable libfluid_msg library is not accessible from an untrusted network.
The OpenFlow Protocol
OpenFlow is a key technology in software-defined networking (SDN) that makes it easier to manage network devices like switches and routers from a central location. Initially developed at Stanford University and now managed by the Open Networking Foundation, OpenFlow allows networks to be more flexible and quickly adapt to changing business needs.
OpenFlow is a Software-defined networking (SDN) protocol
The core principle behind OpenFlow is the separation of the network’s control plane from the data (or forwarding) plane. In traditional networks, each switch or router has its own control plane so that each appliance makes independent decisions about where to send packets. OpenFlow changes this idea by centralizing the control logic. In this new model, the controller, which runs in a remote computer, uses the OpenFlow protocol to instruct network devices (e.g., switches) on how to make forwarding decisions and how traffic flows should be handled across the entire network. Leveraging this capability, network administrators can configure an entire network infrastructure remotely and in a unified way, avoiding the manual re-configuration of each appliance if the network changes.
Key components
To achieve this goal, a communication standard must be built between controllers and forwarders to allow the controller to directly access the forwarding plane of network devices. OpenFlow provides this standard. It introduces the concept of a flow table, which is essentially a set of instructions used by forwarders to determine how to handle and route data packets. The OpenFlow protocol enables controllers to install these flow tables into the forwarders through a specific interface. By doing so, the controller can directly influence and control how data is moved around in the network. This makes networks more flexible and programmable, allowing for more efficient routing based on current network conditions and requirements.
Controller
An OpenFlow controller acts as the brain of the SDN architecture. It is located at the control logical layer, and is used manage the data forwarding layer through the OpenFlow protocol. The controller typically offers two types of logical interfaces:
- Northbound: This interface consists of all programming interfaces used by developers to build functionalities on top of the controllers, such as network services and applications.
- Southbound: This interface responsible for interacting with network devices to program their behavior into the network. Through this channel, the controller manages and controls switches, receiving feedback from them as well. The messages exchanged over the OpenFlow channel must adhere to the format specified by the OpenFlow protocol. This channel is usually encrypted using Transport Layer Security (TLS), although it can run directly in plain text over TCP protocol.
Forwarder
An OpenFlow forwarder, whether physical or virtual, is a core component of the OpenFlow network, responsible for data layer forwarding. It forwards packets based on the flow table, which contain:
- Match Fields: match incoming packets.
- Counters: keep statistics on matched packets.
- Actions: specify what to do with matched packets (e.g., forwarding, dropping, or modifying).
Flow entries are generated, maintained, and delivered by the controller. When an OpenFlow forwarder (e.g., switch) receives a packet that it has never seen before, for which it has no matching flow entries, it sends this packet to the controller. The controller then decides on how to handle this packet. It can drop the packet, or it can add a flow entry directing the switch on how to forward similar packets in the future.
The libfluid Framework
To promote and accelerate the adoption of software-defined networking (SDN) protocols, the ONF opened the “OpenFlow Driver Competition”. The goal of this competition was to foster the development of an OpenFlow open-source library so that anyone, from network equipment vendors and operators to open-source projects, could freely use it, reducing the entry cost and time-to-market needed to implement the OpenFlow protocol. At the end of the competition, the libfluid framework was selected as the winner of the competition.
Building OpenFlow messages
The libfluid framework is uniquely designed without a built-in tool for creating and interpreting network messages. Instead, it allows developers to work with high-level, user-friendly representations of OpenFlow messages. When messages are received from the network, they're transformed into a more straightforward format that developers can easily understand and manipulate. Similarly, when developers need to send messages, they craft these using the same simplified format: the high-level object is converted into the binary format and then sent over the network through the OpenFlow channel.
Although libfluid itself does not include message handling capabilities, it supports the use of external libraries for this purpose. One such library, called libfluid_msg, is fully compatible with the framework and available for those who want a direct way to manage OpenFlow messages. This flexibility allows users to customize their setup according to their specific requirements.
Research Target: libfluid_msg
The focus of our security research was the libfluid_msg module, the standalone messaging library within the libfluid framework. This library plays a crucial role in network communication by simplifying the creation and the processing of OpenFlow messages for controllers and switch agents. The library achieves this goal through classes that provide methods for packing (marshalling) and unpacking (unmarshalling) data. When an object is packed, it is converted into an OpenFlow message in the correct network byte order, ready to be sent across the network. Vice versa, unpacking involves parsing the network data (adjusting the byte order as needed) and converting it into C++ objects that developers can easily manipulate.
Parsing libraries like libfluid_msg have a core role in network protocols since they handle the critical task of translating complex network data into manageable formats, which means they can also be a significant vulnerability if not properly secured. Several high-profile security breaches such as LogoFAIL and ForcedEntry have exploited weaknesses in parsing libraries, demonstrating the critical importance of robust security practices in their development.
Discovered Vulnerabilities
Nozomi Networks Labs identified a total of 37 vulnerabilities affecting the the libfluid_msg library. They can be grouped by the following CWEs and corresponding CVSSv3.1 scores:
- CWE-125: Out-of-Bounds Read (27)
- CVSSv3.1: Medium (6.5) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
- CWE-690: Unchecked Return Value to NULL Pointer Dereference (9)
- CVSSv3.1: Medium (5.3) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
- CWE-170: Improper Null Termination (1)
- CVSSv3.1: Medium (5.3) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Impacts and Attack Scenarios
These vulnerabilities have been identified in the “unpack” method of C++ classes in charge of unmarshalling the raw bytes received over the network from the OpenFlow controller/forwarder and converting into the corresponding C++ object that represent the OpenFlow message. Due to these software defects, if an OpenFlow controller/forwarder uses the vulnerable libfluid_msg library to process a malicious OpenFlow network packet, then a memory leak or a segmentation fault could occur in the target application that processes the raw bytes. Due to these issues, an attacker with network visibility to an OpenFlow controller/forwarder can send a malicious OpenFlow network packet that leads to a Denial-of-Service (DoS) attack.
Disclosure timeline
After discovering the libfluid_msg library security vulnerabilities, Nozomi Networks Labs made several attempts to contact the ONF through various channels to report these issues. Despite also reaching out via the VINCE reporting platform with CERT/CC, we received no response from ONF. As a result, at the time of writing, the open-source code of the libfluid_msg library remains unpatched for the vulnerabilities discussed in this blog post. The table below outlines the timeline of our disclosure process:
