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
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?
- Tags: ROS, security, vulnerabilities
Recent Posts
Categories
Have Any Question?
- contact@asimovsec.com