ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Cybersecurity in the ROS 2 communication middleware, targeting the top 6 DDS implementations

Dear all,

I’m happy to share the results of a cybersecurity research project I’ve been involved in for the past months and which results from a cooperation among various teams within the community. 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. We’re now bringing this to the attention of the ROS community to raise awareness.

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, wecan 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.

ROS 2 reconnaissance PoC

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.

ROS 2 reflection attack

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.

ROS 2 Node crashing

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):

We’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.

12 Likes