Although parameters are usually set in parameter files, they can also be changed by nodes. Specifically, other nodes in the same ROS application can also change the parameters listed above before it’s used, either by accident or intentionally (i.e., by potential attackers). For example, the moveit_interactive_marker node reads from parameter ~prefix to decide the topic to publish. If the ~prefix parameter is changed, the moveit_interactive_marker cannot receive messages from and publish messages to the correct topics, which disables the control input of the victim robot. If an attacker exists, she can even manipulate the victim robot. For example, she can change /goal_interactive_moveit/prefix parameter from goal to goal_fake, which disables the functionality of the interactive marker. Then, she can send anything she wants to the /update_goal_joint_position topic. She can also forward the message between the correct topics and the fake topics while monitoring the contents, and modify some data as she wants to. Because ROS is an OSS (open-source software) community, third-party nodes are widely used in ROS applications, usually without complete vetting of their behavior, which gives the opportunity to potentially malicious actors to inject malicious code (e.g, by submitting hypocrite commits like in other OSS systems [1]) to infiltrate the ROS applications that use it (or software supply chain attacks, one of the primary means for real-world attackers today [2]).
We understand that using parameters to set topic names brings flexibility. Still, for the purpose of security, we strongly suggest that you avoid such vulnerable programming patterns if possible. For example, to avoid the exposure of this specific vulnerability, you may consider alternatives like remapping, which is designed for configuring names when launching the nodes.
Hi there, I wanted to follow up on this security vulnerability. Could you please let me know if there have been any updates or concerns regarding this issue? Thanks
Hi,
We notice that you are using topic names from ROS parameters at the following locations: https://github.com/tork-a/visualization_rwt/blob/6a14ae64aeebe52854a5711816aa56fc0bffe6c6/rwt_moveit/nodes/interactive_moveit.py#L133 https://github.com/tork-a/visualization_rwt/blob/6a14ae64aeebe52854a5711816aa56fc0bffe6c6/rwt_moveit/nodes/interactive_moveit.py#L134 https://github.com/tork-a/visualization_rwt/blob/6a14ae64aeebe52854a5711816aa56fc0bffe6c6/rwt_moveit/nodes/interactive_moveit.py#L135 https://github.com/tork-a/visualization_rwt/blob/6a14ae64aeebe52854a5711816aa56fc0bffe6c6/rwt_moveit/nodes/joint_state_publisher#L76 https://github.com/tork-a/visualization_rwt/blob/6a14ae64aeebe52854a5711816aa56fc0bffe6c6/rwt_moveit/nodes/virtual_joint_state_publisher#L79 For security reasons detailed below, we strongly suggest avoiding the usage of strings from parameters as topic names.
Although parameters are usually set in parameter files, they can also be changed by nodes. Specifically, other nodes in the same ROS application can also change the parameters listed above before it’s used, either by accident or intentionally (i.e., by potential attackers). For example, the moveit_interactive_marker node reads from parameter
~prefix
to decide the topic to publish. If the~prefix
parameter is changed, the moveit_interactive_marker cannot receive messages from and publish messages to the correct topics, which disables the control input of the victim robot. If an attacker exists, she can even manipulate the victim robot. For example, she can change/goal_interactive_moveit/prefix
parameter fromgoal
togoal_fake
, which disables the functionality of the interactive marker. Then, she can send anything she wants to the/update_goal_joint_position
topic. She can also forward the message between the correct topics and the fake topics while monitoring the contents, and modify some data as she wants to. Because ROS is an OSS (open-source software) community, third-party nodes are widely used in ROS applications, usually without complete vetting of their behavior, which gives the opportunity to potentially malicious actors to inject malicious code (e.g, by submitting hypocrite commits like in other OSS systems [1]) to infiltrate the ROS applications that use it (or software supply chain attacks, one of the primary means for real-world attackers today [2]).We understand that using parameters to set topic names brings flexibility. Still, for the purpose of security, we strongly suggest that you avoid such vulnerable programming patterns if possible. For example, to avoid the exposure of this specific vulnerability, you may consider alternatives like remapping, which is designed for configuring names when launching the nodes.
[1] Q. Wu and K. Lu, “On the feasibility of stealthily introducing vulnerabilities in open-source software via hypocrite commits,” 2021, https://linuxreviews.org/images/d/d9/OpenSourceInsecurity.pdf. [2] Supply chain attacks are the hacker’s new favourite weapon. and the threat is getting bigger. https://www.zdnet.com/article/supply-chain-attacks-are-the-hackers-new-favourite-weapon-and-the-threat-is-getting-bigger/.