Exploits & Vulnerabilities
Critically Underrated: Studying the Data Distribution Service (DDS) Protocol
Researchers from Trend Micro Research, TXOne, ADLINK, Alias Robotics, and ZDI looked into the Data Distribution Service (DDS) standard and its implementations from a security angle. The full findings of this research will be presented in the S4X22 Conference in April 2022.
By Federico Maggi, Rainer Vosseler (Trend Micro Research), Mars Cheng, Patrick Kuo, Chizuru Toyama, Ta-Lun Yen (TXOne Networks), Erik Boasson (ADLINK), and Victor Mayoral Vilches (Alias Robotics)
Despite being unknown even to industry practitioners, the Data Distribution Service (DDS) protocol has been in use for more than a decade. This middleware software technology is responsible for running billions of public and private devices and mechanisms currently in use. DDS is integral in embedded systems that require real-time machine-to-machine communication, facilitating a reliable communication layer between sensors, controllers, and actuators.
This technology is situated at the beginning of the supply chain as a layer that connects, controls, and monitors applications, sensors, and actuators, aimed at maintaining interoperability and fault tolerance. It is used in various critical sectors such as healthcare, transportation, industrial internet of things (IIoT), robotics, aeronautics, and the military, among others. Given these factors, this makes the middleware technology an attractive target for attackers.
We analyzed this software and found multiple security vulnerabilities. This blog lists 13 identified security gaps that were assigned new CVE IDs found in the six most common DDS implementations, mostly concerning deployment. We also show a preview of the security gaps we found in the standard’s specification and a summary of our testing procedure. For details on the known vulnerabilities, attack scenarios, and research methodology, read our full paper “A Security Analysis of the Data Distribution Service (DDS) Protocol.” All the vulnerabilities found have been disclosed and patched or mitigated by their respective vendors.
New vulnerabilities
We studied six widely used DDS implementations, chosen based on executions’ number of users and customers in the critical sectors globally. We also looked at each implementation’s real-time publish-subscribe (RTPS) packet, as DDS is dependent on its own lower layer standard protocol.
Notably, we also studied the Robot Operating System 2 (ROS 2) because it uses DDS as its default standard operating system (OS) middleware for all robotics and automation use cases. Given the service’s position as a security and operations building block, all vulnerabilities that affect DDS also affect the rest of the software stack, such as RTPS and all ROS 2 instances.
| Product Name | Developer | HQ Region | Open Source | Core Language | Year Developed |
|---|---|---|---|---|---|
| Fast-DDS | eProsima | EMEA | Apache License 2.0 | C++ | 2014 |
| Cyclone DDS | Eclipse Foundation project, driven by ADLINK | EMEA | Eclipse Public License 2.0 and Eclipse Development License 1.0 | C | 2011 |
| OpenDDS | OCI | NABU | Custom | C++ | 2005 |
| Connext DDS | RTI | NABU | Extensions are open source | C++ | 2005 (NDDS – 1995) |
| CoreDX DDS | TwinOaks | NABU | Not open source | C | 2009 |
| Gurum DDS | GurumNetworks | APAC | Not open source | C |
Table 1. A list of all DDS implementations analyzed for this research.
| MITRE ATT&CK ICS | Attack Surface | Vector | CVE | Scope | CVSS | Weaknesses (CWE) |
|---|---|---|---|---|---|---|
T0804: Brute Force I/O T0814: DoS T0827: Loss of Control T0880: Loss of Safety T0802: Automated Collection T0846: Remote System Discovery T0856: Spoof of Reporting Message |
Network | RTPS discovery packet | CVE-2021-38425 | Fast-DDS, ROS 2 | 7.5 | CWE-406: Network amplification |
| CVE-2021-38429 | OpenDDS, ROS 2 | 7.5 | ||||
| CVE-2021-38487 | Connext DDS, ROS 2 | 7.5 | ||||
| CVE-2021-43547 | CoreDX DDS, ROS 2 | 7.5 | ||||
| Malformed RTPS packet | CVE-2021-38447 | OpenDDS, ROS 2 | 8.6 | CWE-405: Network amplification | ||
| CVE-2021-38445 | OpenDDS, ROS 2 | 7.0 | CWE-130: Improper handling of length | |||
| CVE-2021-38423 | Gurum DDS, ROS 2 | 8.6 | CWE-131: Incorrect calculation of buffer size | |||
| CVE-2021-38435 | Connext DDS, ROS 2 | 8.6 | ||||
| CVE-2021-38439 | Gurum DDS, ROS 2 | 8.6 | CWE-122: Heap-based buffer overflow | |||
T0862: Supply Chain Compromise T0839: Module Firmware T0873: Project File Infection |
Configuration | XML file | CVE-2021-38427 | Connext DDS, ROS 2 | 6.6 | CWE-121: Stack-based buffer overflow |
| CVE-2021-38433 | Connext DDS, ROS 2 | 6.6 | ||||
| CVE-2021-38443 | Cyclone DDS, ROS 2 | 6.6 | CWE-228: Improper handling of syntactically invalid structure | |||
| CVE-2021-38441 | Cyclone DDS, ROS 2 | 6.6 | CWE-123: Write-what-where condition |
Table 2. A summary of our findings across the main DDS implementations and standard specification.
When the security gaps on the network attack surface are exploited, it allows an attacker to perform spoofing, reconnaissance, automated data collection, and denial of service (DoS), affecting the control of an exposed system. Meanwhile, the vulnerabilities we found on the configuration attack surface can be abused to affect the DDS developer or system integrator, potentially compromising the integrity of the software supply chain.
Vulnerabilities in the standard specification
The built-in RTPS discovery protocol is used in peer-to-peer networks to discover the locator of each participant (such as IP address and UDP/TCP port or offset in shared memory). The “chatty” nature of this discovery protocol and the fact that it expects a reply from each contacted participant, paired with easy-to-spoof transport protocols such as the User Datagram Protocol (UDP), make RTPS vulnerable to network reflection and amplification. Confidentiality and authenticity for this data is not protected even with DDS Security, making it possible for an attacker to spoof the information.
| CVE ID | Scope | Partially Mitigated* | BAF | Percentage of Attack Duration (Total experiment duration = 139s) |
|---|---|---|---|---|
| CVE-2021-38425 | Fast-DDS, ROS 2 | master branch | 9.875 | 100.0 |
| CVE-2021-38429 | OpenDDS, ROS 2 | >= 3.18.1 | 18.68 | 24.17 |
| CVE-2021-38487 | Connext DDS, ROS 2 | >= 6.1.0 | 2.011 | 84.17 |
| CVE-2021-43547 | CoreDX DDS, ROS 2 | > 5.9.1 | 32.82 | 18.14 |
Table 3. The network reflection and amplification vulnerability with bandwidth amplification factor (BAF) is calculated as the ratio between outbound and reflected traffic.
Note: Implementations with less than 100% attack duration likely have a timeout mechanism. (*) A full mitigation will require relevant changes in the RTPS specification.
The longest running node was based on Connext DDS (at 139 seconds), which we kept as a reference. Table 3 shows that the BAF is greater than one, implying there are asymmetric network flows although the values are at the order of magnitude lower than modern amplification attacks (note that Memcached can reach 10,000 to 51,000 BAF). However, the network bandwidth in embedded systems is also lower than, for example, what internet nodes can provide.
An attacker can abuse this built-in discovery feature for remote discovery and fingerprinting. We sent RPTS discovery probes to the entire IPv4 space (except for the no-scan subnets) and received answers from 643 hosts (excluding obvious honeypots). Notably, hosts never stopped sending traffic to us, even if we only sent them a single 288-byte packet.
This new network-reflection vulnerability that we found is not the only instance of a specification-level vulnerability. Security researchers from different organizations have been documenting and creating attack scenarios abusing these vulnerabilities as early as 2015.
Conclusion
Proper supply chain management processes allow contextualization, tracking, and monitoring of new vulnerabilities within different downstream software using a specific library such as DDS. In the case of this middleware technology, DDS is just one of the many critical libraries used in embedded applications that’s easy to lose track of. Our paper, “A Security Analysis of the Data Distribution Service (DDS) Protocol,” includes short- and long-term mitigation best practices and recommendations, as well as a consideration for adopting a shift-left approach.
We also acknowledge the cooperation and engaging response that some vendors like ADLINK have adopted when we approached them with our findings. As we encourage more DDS researchers, users, and implementors to keep on studying and promoting security awareness for the DDS ecosystem, we hope the level of engagement we received can serve as a model for the software industry.
Download our full paper here.