Security pitfalls in ROS based robots

First released in 2009, Robot Operation System (ROS) is a middleware widely used by robotic applications. Since its inception, it has gained significant interest in robotics research. Over the past few years, the industry has also witnessed an increase in interest. By providing an abstraction layer for interacting with hardware sensors and actuators, ROS simplifies the development of robots and other similar applications. Security considerations are especially relevant when ROS is used to control actuators in the physical world. A loss of functionality or maliciously injected commands can have a severe impact and cause the robot to damage itself, the physical environment or even harm people.

Currently, there are two major versions of ROS:

ROS

ROS uses its own middleware implementation, which cannot be customized. One coordination node known as the “master” manages the ROS setup and provides parameters to the entire ROS network. A publish-subscribe architecture is used to configure ROS nodes to assign tasks to them and interact with each other. In ROS-based systems, communication takes place through generic networking protocols like TCP and UDP. There are some limitations to ROS 1, especially in the area of real-time computing, and it does not offer any protection. The last official ROS release was published in May 2020. It will be supported until May 2025. After that, users will have to migrate to ROS2 in order to receive support and updates.

ROS 2

The successor to ROS is ROS 2. Many of the basic concepts and ideas of ROS (such as the publish-subscribe architecture) are retained, but some significant changes have been made to core mechanics to address changing requirements. As a result, ROS 2 is incompatible with ROS 1. Firstly, ROS2 has abandoned its central master component, which is a fundamental difference. In place of this, nodes use auto-discovery to find one another, making it easier to implement a modular distributed system. Another fundamental difference is the use of Data Distribution Service (DDS) middleware, which allows ROS 2 to be configured to match the target setup based on Quality of Service (QoS) parameters. It is possible to choose between different DDS implementations offered by different vendors and the DDS standard provides optional security extensions that are disabled in ROS 2 by default.

Lets Build a Robot

For the sake of the article let’s build a hypothetical ROS robot and analyze the possible security pitfalls in the process.

Our hypothetical robot will have to be able to perform a “pick and place” task, and for this we will have to equip it with a gripper arm to pick and hold the object, a camera to be able to see the object, a mobile platform to move around the space and a computational unit for processing and transmission of data (for our example a raspberry pi will suffice). The final product of a robot is an art of integrating those various systems.

We will also need to write a lot of code if we are to cover every single thing ourselves. This includes target detection, localization, arm movement and many other features that we are not intending to dive into in this post.

It is worth noting at this point that ROS is an open-source project essentially composed of hundreds of different packages.

An index is available for anyone to look into all publicly available packages.

Once you decide to build a robot with ROS it is inevitable to search for packages that already do the work for you. However, if a package does not exist or you wish to contribute to the community, adding a package to the index is not a difficult task, even for the less tech-savvy explorer, and the verification process is almost non-existent.

For example, the ROS Navigation Stack (called “navigation”), is a 2D navigation stack, and in itself it depends on not less than 17 other ROS packages

In another example, the gps_tools package from the gps_umd repository, which provides the GPS routines for use in GPS drivers, depends on 9 additional ROS packages

In yet another example, the mrpt2 package from the mrpt2 repository, a toolkit that provides applications and libraries covering data structures and algorithms employed in common robotics research areas. It depends on 33 other ROS packages.

In this regard, ROS packages bring a considerable amount of foreign code into our environment. There is a possibility that this code contains a vulnerability or even a malicious piece of code. Since there are no safeguards this malicious piece of code can easily find its way into our robotic setup.

So we found our first security pitfall – foreign, possible harmful code that could enter into our systems through the open-source code that is used in our setup.

But I already scan my code for vulnerabilities with X

Traditionally, security tools are not designed with robotics in mind. They are not prepared to detect ROS vulnerabilities and ROS malicious code, which is why we have developed Asimov Security. We invite you to view our product in action to understand the difference.

Back to our robot

First, let’s discuss the integration of subsystems with the ROS publish & subscribe paradigm. In ROS, a so-called node is a stand-alone process that interacts with other processes via topics. There is a topic for each stream of data of a particular type. Subscribing to the data stream allows interested parties to read data and, in turn, create their own topics where they publish data they have produced. Thus, a graph of information flows is created.

For our robot we could configure the nodes in the following manner:

option 1 – no external hosts

Overall, two ROS nodes are configured: one for vision, which publishes the coordinates of close objects, and another for the master node, which communicates with the Arduino controller (that controls the arm movement) and, if the arm is ready and the target is within reach, executes the grasping command. While there is no grasping action in progress, the master node communicates with the mobile base platform to produce motion.

Option 2 – host for each sub-system

Here each of the systems is running on a separate host device

The question for both of this options is how exactly do the nodes communicate?

There is a clear distinction between ROS application control (finding a publisher for a topic I wish to subscribe to) and ROS data transfer. The former is handled through the XML-RPC API, and the latter is handled by TCP or UDP based communication. Security concerns regarding confidentiality, integrity, or authenticity were not considered in either case. ROS nodes do not need to identify or authenticate themselves before taking any action. Moreover, the stateless API ignores what is occurring on the network. Many of these design decisions seem very elegant from the perspective of software development, however, this leaves ROS susceptible to several attacks. Other than the possibility of disabling individual nodes (as a form of DOS attack), eavesdropping is extremely easy since ROS’s communications are not encrypted. As a result, anyone can read the information transmitted by the application.

Two publicly available tools are available for performing attacks on ROS applications: roschaos and ROSPenTo.

The ROS Master API does not require authentication for registration and deregistration of publishers, subscribers, and services. This leads to a vulnerability that can be easily exploited using off-the-shelf penetration testing tools by an attacker who has access to the internal robotic network.

We will get back to our robot in part 2 of the series on ROS security where we will discuss more ROS based attacks and explore examples.

Stayed tuned!

Tags: ROS, security, vulnerabilities