Security vulnerabilities on the Data Distribution Service (DDS)

Learn more about DDS, and how to stay protected while using it

If you are currently running the Robot Operating System 2 (ROS 2), this piece is especially relevant to the security of your robots. A few weeks ago, a group of security researchers reported 13 security vulnerabilities affecting some of the most used implementations of DDS, the default middleware used by ROS 2.

What is DDS? A quick refresher

The Data Distribution Service (DDS) for real-time systems is an open middleware protocol and API standard by the Object Management Group (OMG). It implements a publish-subscribe communication pattern for real time and embedded systems, that allows participants to send and receive data, events and commands transparently. There are currently more than ten unique DDS implementations, some are open source and some are not.

DDS is designed around industrial-level requirements, defining a well-supported standard with a long history of use. It is nowadays being used in a wide range of industries: autonomous vehicles, space systems, air traffic management, healthcare devices, and, as we know, ROS 2.

Before moving on to the reported issues and risks, let’s remind ourselves that DDS is concerned with security by design; it has security features baked in into its very standard definition, such as these 5 key features: 

• Cryptography: implements encryption, decryption, hashing, and digital signatures;
• Authentication: takes care of checking the identity of all participants in a network;
• Access Control: specifies which resources a given participant can access and modify; and
• Security logging: records all security-relevant events.
• Data Tagging: enables adding security labels to the data, which makes it possible to specify classification levels and implement better access control.

What’s the security news?

A team of researchers analyzed the DDS middleware and its most popular implementations for security vulnerabilities. They shared their findings for the first time at the Black Hat Europe Conference 2021, which the Canonical Robotics team attended. A presentation was also offered especially for the ROS 2 Security Working Group (SWG) earlier today. Remember you can follow the SWG’s different channels to keep up with such news and join the monthly meetings!

Now to the findings: as a result of this project, 12 vulnerabilities were found across the six DDS implementations analysed, plus one vulnerability in the standard specifications. The issues were present in multiple vendors’ implementations, including Connext DDS, CoreDX DDS, CycloneDDS, FastDDS, GurumDDS, and OpenDDS.

These 13 vulnerabilities have been reported, and registered as Common Vulnerabilities and Exposures (CVE). Of these, seven have a ‘High’ base severity rating based on FIRST’s Common Vulnerability Scoring System (CVSS) v3, while the other five received a ‘Medium’ base score. In this scoring system, vulnerabilities in the “base” group represent intrinsic qualities, constant over time and across user environments.

Following these reports, the US Cybersecurity and Infrastructure Security Agency (CISA) released a security advisory warning of their cybersecurity implications. Mitigation measures were also promptly made available by multiple DDS vendors. More details and links can be found in the CISA’s advisory.

Today we’ll crunch the details for you, about what these issues are, what has been done by the vendors involved, and what actions you should take now to stay protected.

What were some of the issues found, and what has been done about them?

In short, they can be broken down into 2 categories: network-based, and configuration-based vulnerabilities.

Network-based vulnerabilities

Since DDS is a network-based protocol, an obvious place to look for security issues are the message interpretation routines (such as permitted lengths of a field, where e.g. overflows could potentially happen). For this, the researchers dissected and analysed the foundational layer of the DDS ecosystem: RTPS, or Real-Time Publish-Subscribe protocol.

The first issue worth mentioning is a network reflection/amplification vulnerability (CVSS base score of 8.2 out of 10) affecting all implementations, which indicates it is an issue on the DDS standard itself (CVE-2021-38425, CVE-2021-38429, CVE-2021-38487, CVE-2021-43547). This vulnerability could allow an attacker to send malformed RTPS packets to flood a target host with unwanted traffic, and thus potentially carry out a Denial-of Service (DoS) attack or cause information exposure. This kind of vulnerability is registered as Common Weakness CWE-406, and you can learn more about it here. Another related issue found on the DDS spec was a lack of IP sanitization, meaning that one could write any arbitrary IPs into the IP field (no sanity checks or address safelisting).

What has been done?

• eProsima recommends users apply the latest Fast DDS patches.
• OCI recommends users update to Version 3.18.1 of OpenDDS or later.
• Twin Oaks Computing recommends users apply CoreDX DDS Version 5.9.1 or later, which can be downloaded on the Twin Oaks website
• Contact RTI Support for mitigations, including how to use RTI DDS Secure to mitigate against the network amplification issue defined by CVE-2021-38487
• Users of GurumNetworks should contact them directly for assistance.

Configuration-based vulnerabilities

DDS configuration makes extensive use of XML, JSON, YAML, or similar formats; therefore configuration files were another attack vector analysed.

One of the vulnerabilities found in one of the implementations was a ‘write-what-where’ condition, which may allow an attacker to write arbitrary values in the XML parser, as a result of a buffer overflow (CVE-2021-38441). The same implementation was also found to improperly handle syntactically invalid structures, which similarly can be exploited to write arbitrary values into the XML parser. Processing such input could lead to undefined behavior and cause the system to crash (CVE-2021-38443).

A few other parsing vulnerabilities related to improper calculation of buffer size, and stack-based buffer overflows. One of these could be exploited to partially overwrite the instruction pointer; another, to partially control the stack up to the environment variables. These are also recognised as CWE-121 and CWE-131; this last one can even lead to an incidence of CWE-119, one of 2021’s Top 25 Most Dangerous Software Weaknesses (CWE Top 25).

Finally, it was found that yet another implementation was using an old, unmaintained and vulnerable XML library, which allows an attacker to use a malicious configuration file to gain initial access.

What has been done?

• Eclipse recommends users apply the latest CycloneDDS patches.
• RTI recommends users apply the available patches, available on the RTI customer portal or by contacting RTI Support.
• Users of GurumNetworks should contact them directly for assistance.

What should you do now?

As you can see, the vast majority of DDS vendors have released security patches or otherwise mitigated these vulnerabilities. If you are running ROS 2 with any of these DDS implementations, apply any security patches made available by your vendor as soon as possible.

Then, notice that because DDS is deployed locally, from an attacker’s standpoint, DDS is most attractive for local attack opportunities; such as, discovery of other endpoints, lateral movements, and executing command and control attacks (where an attacker manages to remotely control a system compromised with malware). This is why it’s a good idea to apply defensive security strategies on your robots, and minimise the risk that any such issues could be exploited. A good resource to get started are NIST’s Guide to Industrial Control Systems (ICS) Security or CISA’s recommended practices for securing ICS, many of which robotics systems can benefit from. 

Last but not least: finding, reporting and mitigating vulnerabilities affecting ROS-based systems benefits the entire community! We encourage you to also report (and actively search for, why not) any vulnerabilities present in relevant components. And if you find any, you can refer to the ROS 2 Vulnerability Disclosure Policy for the right way to report it.

And for ROS-specific security recommendations, download Canonical’s robotics security whitepaper, and check out our recent security-focused presentation given at the ROS Industrial (ROS-I) Europe Conference 2021.