You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
Such changes can lead to denial-of-service and even man-in-the-middle attacks. In the map_merge case, both the input and output map topics are configured through parameters, which means changes to these parameters may lead to interruption of service, and the downstream applications cannot receive a merged map. If an attacker exists, she can even first fool the map_merger to publish to a fake topic e.g. /map_fake, then sending a modified map based on the map from topic /map_fake to topic /map that is actually used by downstream applications. Considering the functionality of downstream applications, the victim robots may fail to navigate, or even crash into obstacles, just as the attacker wants. Similarly, for explore_lite package, changes to ~/costmap_topic and ~/costmap_updates_topic parameters can lead to failure of navigation and even crashes. 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:
m-explore/explore/src/costmap_client.cpp
Line 68 in fe0e0f3
m-explore/explore/src/costmap_client.cpp
Line 81 in fe0e0f3
m-explore/map_merge/src/map_merge.cpp
Line 67 in 06de4b6
m-explore/map_merge/src/map_merge.cpp
Line 127 in 06de4b6
m-explore/map_merge/src/map_merge.cpp
Line 135 in 06de4b6
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).
Such changes can lead to denial-of-service and even man-in-the-middle attacks. In the map_merge case, both the input and output map topics are configured through parameters, which means changes to these parameters may lead to interruption of service, and the downstream applications cannot receive a merged map. If an attacker exists, she can even first fool the map_merger to publish to a fake topic e.g.
/map_fake
, then sending a modified map based on the map from topic/map_fake
to topic/map
that is actually used by downstream applications. Considering the functionality of downstream applications, the victim robots may fail to navigate, or even crash into obstacles, just as the attacker wants. Similarly, for explore_lite package, changes to~/costmap_topic
and~/costmap_updates_topic
parameters can lead to failure of navigation and even crashes. 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/.
The text was updated successfully, but these errors were encountered: