More about DDS and how to secure it. If you're currently using Robot Operating System 2 (ROS 2), this material is especially relevant to securing your robots. A couple of months ago, a research team discovered thirteen safety flaws that affect some of the core implementations of DDS, the intermediate software by default found in ROS 2.
What is DDS?
DDS is designed for real-time applications and is an open-source middleware application protocol and API standards created by the Object Management Group (OMG). It features a publish-subscribe connection scheme for real-time and inline systems, enabling members to send and accept commands, and events. To date, there are over a dozen different implementations of DDS, some with an open version and some without.
DDS was created based on industry needs, resulting in a widely supported standard with a long history of use. It is currently used in a wide variety of industries: autonomous vehicles, space technology, air traffic control, medical equipment, and, as we know, ROS 2.
Before we get into the known issues and risks, let's remember that DDS has been concerned with security since its inception; it has security elements provided for in the standard understanding, such as these 5 basic elements
- Cryptography: provides the ability to encrypt, decrypt, hash, and use digital signatures;
- Authentication: performs identity verification of all network users;
- Access control: specifies which resource a given user can access and modify;
- Security data logging: captures all security-related events.
- Data Tagging: provides security tags on the data, which allow a level of classification and a higher level of access control.
What's new in security?
Experts analyzed the DDS middleware platform and its most common implementations for security vulnerabilities. They shared their findings for the first time at the Black Hat Europe 2021 conference, which was attended by the Canonical Robotics team.
The project identified 12 weaknesses in the six DDS implementations analyzed, as well as one vulnerability in a standard specification. These vulnerabilities were found in several developers' implementations. Following these reports, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) published a security advisory warning of their cybersecurity risks.
What was the nature of the problems?
What were some of the problems found, and what was done about them?
In short, these vulnerabilities can be roughly categorized into two classes: network-related problems and configuration-related threats.
Network-related vulnerabilities
Considering that DDS is a network protocol, the security problems should be looked for in the procedures of message interpretation (such as allowed field lengths, where for example, an overflow is possible). In this regard, experts have parsed and studied a fundamental element of the DDS ecosystem. The first problem worth mentioning was a network reflection/reinforcement vulnerability that affected all implementations, suggesting a problem in the DDS standard itself.
With this vulnerability, an attacker could transmit improperly crafted RTPS packets, causing the target host to flood with unnecessary traffic and thus a potential denial-of-service attack or disclosure of system information.
Another issue found in the DDS specification was insufficient I.P. address sanitization. It was possible to write an arbitrary I.P. address into the I.P. field (without integrity checks or a secure address list).
Configuration-based vulnerability
XML, JSON, YAML, or related file formats are heavily used in DDS configurations, making it another attack target to analyze configuration files. One implementation discovered a 'write-what-where' vulnerability that allowed an intruder to put random numbers into an XML parser in the event of a buffer overflow. The same implementation was also found to mishandle syntactically invalid structures, which could also be used to put random meanings into an XML parser. Handling such data can lead to undefined behavior and system crashes.
Some other parsing vulnerabilities concerned the improper calculation of buffer volume and buffer overflows based on the stack.
Finally, another implementation was found to use an outdated, unsupported, and vulnerable XML library, giving an attacker the ability to gain initial access with a malicious configuration file.
Note that many DDS vendors have published security updates or otherwise patched these vulnerabilities. If you are running ROS 2 with any of the listed DDS implementations, apply any vendor-provided security patches as soon as possible.
