During the last few months I've been involved with a cybersecurity research group where we've been studying the security of ROS 2 through its underlying communication middleware: DDS (Data Distribution Service). The results have been responsibly disclosed to affected parties over the past few months. We also followed a coordinated disclosure approach in cooperation with authorities, which was made public first in this security advisory, and later in our public talks. After bringing this to the attention of the ROS community to raise awareness, I'm also sharing a few bits in here:
TL;DR: Our target this time was studying the underlying default communication middleware of ROS 2: OMG's Data Distribution Service (DDS) and its most popular implementations. We found all DDS implementations vulnerable to various attacks and demonstrated how ROS 2 systems can be compromised easily due to the insecurities detected at this layer.
Our results are summarized in the table below.
| CVE ID | Description | Scope | CVSS | Notes |
|---|---|---|---|---|
| CVE-2021-38445 | OCI OpenDDS versions prior to 3.18.1 do not handle a length parameter consistent with the actual length of the associated data, which may allow an attacker to remotely execute arbitrary code. | OpenDDS, ROS 2* | 7.0 | Failed assertion >= 3.18.1 |
| CVE-2021-38447 | OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition. | OpenDDS, ROS 2* | 8.6 | Resource exhaustion >= 3.18.1 |
| CVE-2021-38435 | RTI Connext DDS Professional, Connext DDS Secure Versions 4.2x to 6.1.0, and Connext DDS Micro Versions 3.0.0 and later do not correctly calculate the size when allocating the buffer, which may result in a buffer overflow | RTI ConnextDDS, ROS 2* | 8.6 | Segmentation fault via network >= 6.1.0 |
| CVE-2021-38423 | All versions of GurumDDS improperly calculate the size to be used when allocating the buffer, which may result in a buffer overflow. | GurumDDS, ROS 2* | 8.6 | Segmentation fault via network |
| CVE-2021-38439 | All versions of GurumDDS are vulnerable to heap-based buffer overflow, which may cause a denial-of-service condition or remotely execute arbitrary code. | GurumDDS, ROS 2* | 8.6 | Heap-overflow via network |
| CVE-2021-38441 | Eclipse CycloneDDS versions prior to 0.8.0 are vulnerable to a write-what-where condition, which may allow an attacker to write arbitrary values in the XML parser. | CycloneDDS, ROS 2* | 6.6 | Heap-write in XML parser |
| CVE-2021-38443 | Eclipse CycloneDDS versions prior to 0.8.0 improperly handle invalid structures, which may allow an attacker to write arbitrary values in the XML parser. | CycloneDDS, ROS 2* | 6.6 | 8-bytes heap-write in XML parser |
| CVE-2021-38427 | RTI Connext DDS Professional, Connext DDS Secure Versions 4.2x to 6.1.0, and Connext DDS Micro Versions 3.0.0 and later are vulnerable to a stack-based buffer overflow, which may allow a local attacker to execute arbitrary code | RTI ConnextDDS, ROS 2* | 6.6 | Stack overflow in XML parser >= 6.1.0 |
| CVE-2021-38433 | RTI Connext DDS Professional, Connext DDS Secure Versions 4.2x to 6.1.0, and Connext DDS Micro Versions 3.0.0 and later are vulnerable to a stack-based buffer overflow, which may allow a local attacker to execute arbitrary code. | RTI ConnextDDS, ROS 2* | 6.6 | Stack overflow in XML parser >= 6.1.0 |
| CVE-2021-38487 | RTI Connext DDS Professional, Connext DDS Secure Versions 4.2x to 6.1.0, and Connext DDS Micro Versions 3.0.0 and later are vulnerable when an attacker sends a specially crafted packet to flood victims’ devices with unwanted traffic, which may result in a denial-of-service condition. | ConnextDDS, ROS 2* | 8.6 | Mitigation patch in >= 6.1.0 |
| CVE-2021-38429 | OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood victims’ devices with unwanted traffic, which may result in a denial-of-service condition. | OpenDDS, ROS 2* | 8.6 | Mitigation patch in >= 3.18.1 |
| CVE-2021-38425 | eProsima Fast-DDS versions prior to 2.4.0 (#2269) are susceptible to exploitation when an attacker sends a specially crafted packet to flood a target device with unwanted traffic, which may result in a denial-of-service condition. | eProsima Fast-DDS, ROS 2* | 8.6 | WIP mitigation in master |
A more detailed explanation for some of the flaws is provided below.
Dissecting ROS 2 network interactions through RTPS
To research ROS 2 communication middleware, we created a network dissector of DDS (more specifically, a Real-Time Publish Subscribe (RTPS) protocol) to tinker with the ROS 2 communications. Refer to the official Pull Request we sent to scapy for our latest prototype.
The package dissector allows to both dissect and craft, which will be helpful while checking the resilience of ROS 2 communications. E.g., the following Python piece shows how to craft a simple empty RTPS package that will interoperate with ROS 2 Nodes:
rtps_package = RTPS(
protocolVersion=ProtocolVersionPacket(major=2, minor=4),
vendorId=VendorIdPacket(vendor_id=b"\x01\x03"),
guidPrefix=GUIDPrefixPacket(
hostId=16974402, appId=2886795266, instanceId=1172693757
),
magic=b"RTPS",
)
ROS 2 reconnaissance
ROS 2 uses DDS as the default communication middleware. To locate ROS 2 computational Nodes, one can rely on DDS discovery mechanisms. Here's the body of an arbitrary discovery response obtained from one of the most popular DDS implementations: CycloneDDS.
0000 52 54 50 53 02 01 01 10 01 10 5C 8E 2C D4 58 47 RTPS......\.,.XG
0010 FA 5A 30 D3 09 01 08 00 6E 91 76 61 09 C4 5C E5 .Z0.....n.va..\.
0020 15 05 F8 00 00 00 10 00 00 00 00 00 00 01 00 C2 ................
0030 00 00 00 00 01 00 00 00 00 03 00 00 2C 00 1C 00 ............,...
0040 17 00 00 00 44 44 53 50 65 72 66 3A 30 3A 35 38 ....DDSPerf:0:58
0050 3A 74 65 73 74 2E 6C 6F 63 61 6C 00 15 00 04 00 :test.local.....
0060 02 01 00 00 16 00 04 00 01 10 00 00 02 00 08 00 ................
0070 00 00 00 00 38 89 41 00 50 00 10 00 01 10 5C 8E ....8.A.P.....\.
0080 2C D4 58 47 FA 5A 30 D3 00 00 01 C1 58 00 04 00 ,.XG.Z0.....X...
0090 00 00 00 00 0F 00 04 00 00 00 00 00 31 00 18 00 ............1...
00a0 01 00 00 00 6A 7A 00 00 00 00 00 00 00 00 00 00 ....jz..........
00b0 00 00 00 00 C0 A8 01 55 32 00 18 00 01 00 00 00 .......U2.......
00c0 6A 7A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 jz..............
00d0 C0 A8 01 55 07 80 38 00 00 00 00 00 2C 00 00 00 ...U..8.....,...
00e0 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 00 00 ................
00f0 74 65 73 74 2E 6C 6F 63 61 6C 2F 30 2E 39 2E 30 test.local/0.9.0
0100 2F 4C 69 6E 75 78 2F 4C 69 6E 75 78 00 00 00 00 /Linux/Linux....
0110 19 80 04 00 00 80 06 00 01 00 00 00 ............
Using the RTPS dissector, we can craft discovery requests and send them to targeted machines, processing the response and determining if any DDS participant is active within that machine and DOMAIN_ID.
Here's one of such packages:
Though DDS implementations comply with OMG's DDS's specification, discovery responses vary among implementations. The following recording shows how while the crafted package allows to determine the presence of ROS 2 Nodes running (Galactic-default) CycloneDDS implementation, when changed to Fast-DDS (another DDS implementation, previously called FastRTPS and the default one in Foxy), no responses to the discovery message are received.
Network discovery responses are different. It's still possible to perform reconnaissance in Fast-DDS systems, but one must engineer the network interactions accordingly. We must note this doesn't mean Fast-DDS is more secure. In fact, we encountered serious security flaws and pitfalls within Fast-DDS that we did not find elsewhere.
ROS 2 reflection attack
Each RTPS package RTPSSubMessage_DATA submessage can have multiple parameters. One of such parameters is PID_METATRAFFIC_MULTICAST_LOCATOR. Defined on OMG's RTPS spec, it allows to hint which address should be used for multicast interactions. Unfortunately, there's no whitelisting of which IPs are to be included in here and all implementations allow for arbitrary IPs in this field. By modifying this value through a package, an attacker could hint a ROS 2 Node (through its underlying DDS implementation) to use a new multicast IP address (e.g. a malicious server that generates continuous traffic and responses to overload the stack and generate unwanted traffic) which can be used to trigger reflection (or amplification) attacks.
An example of such package crafted with our dissector is available here.
Fully avoiding this flaw requires a DDS implementation to break with the standard specification (which is not acceptable by various vendors because they profit from the interoperability complying with the standard provides). Partial mitigations have appeared which implement exponential decay strategies for traffic amplification, making its exploitation more challenging.
This security issue affected all DDS implementations and as a result, all ROS 2 Nodes that build on top of DDS.
ROS 2 Node crashing
Fuzz testing often helps find security flaws due to programming errors in the corresponding implementations. The following two were found while doing fuzz testing in a white-boxed manner (with access to the source code):
| CVE ID | Description | Scope | CVSS | Notes |
|---|---|---|---|---|
| CVE-2021-38447 | OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition. | OpenDDS, ROS 2* | 8.6 | Resource exhaustion >= 3.18.1 |
| CVE-2021-38445 | OCI OpenDDS versions prior to 3.18.1 do not handle a length parameter consistent with the actual length of the associated data, which may allow an attacker to remotely execute arbitrary code. | OpenDDS, ROS 2* | 7.0 | Failed assertion >= 3.18.1 |
They both affected OpenDDS. The recording below demonstrates how these flaws lead ROS 2 Nodes to either crash or execute arbitrary code due to DDS not handling properly the length of the PID_BUILTIN_ENDPOINT_QOS parameter within RTPS's RTPSSubMessage_DATA submessage.
The key aspect in here is the parameterLength value:
PID_BUILTIN_ENDPOINT_QOS(
parameterId=119,
parameterLength=0,
parameterData=b"\x00\x00\x00\x00",
),
Next steps
- Secure DDS extensions: We plan to continue researching DDS and will likely target in the near future the Secure DDS specification. Early results hint that similarly, security might be overly advertised at this point, since various issues are to be addressed and a continued "pentesting attitude" should land among DDS vendors.
- Improving the OMG standard: We are trying to hold discussions with key OMG stakeholders for what concerns RTPS and DDS so that flaws in the specifications are mitigated. By doing this, we're hoping to promote security culture among robotics components (wherein security goes way beyond data encryption and authentication of interactions).
- Maintain the RTPS dissector for the community: We've raised a ticket in the ROS 2 security WG to push this effort forward and maintain this dissector, creating a tool that all roboticists can use to challenge their communications in the future. Hopefully the Security WG can welcome this contribution this time (as opposed to past contribution attempts which were blocked by the Security WG (past
discussion,failed contribution 1,failed contribution 2). - Extend this work to ROS 1: We have an ongoing prototype of a TCPROS dissector that (as per the current plan) will be submitted upstream for scapy integration. If there's anyone interested on it, feel free to ping me.
- More talks to raise awareness: We'll be disseminating this work in a few upcoming sessions:
- ROS Industrial Conference 2021, Breaking ROS 2 security assumptions: Targeting the top 6 DDS implementations. Dec 1-2, 2021, Fraunhofer IPA, Virtual
ROS 2 Security WG(expected to happen in next meeting)- S4x22, A Security Deep Dive Into The DDS Protocol. Jan 27th, 2022, Miami, FL, USA.
Research paper coming soon.
Credit and acknowledgements
This research is the result of a cooperation among various security researchers. The following individuals took part on it (alphabetical order):
- Chizuru Toyama
- Erik Boasson @eboasson
- Federico Maggi @phretor
- Mars Cheng
- Patrick Kuo
- Ta-Lun Yen @evanslify
- Víctor Mayoral-Vilches @vmayoral
I'd like to give special credit to ADLINK, who has collaborated with us throughout the whole process and their security-first attitude is in our opinion the right path towards ensuring cybersecurity.
