boschglobal / locator_ros_bridge

ROS interface to Rexroth ROKIT Locator
Apache License 2.0
6 stars 12 forks source link

Potential vulnerability: topic names from ROS parameters #31

Closed tandf closed 1 year ago

tandf commented 1 year ago

Hi,

We notice that you are using topic names from ROS parameters at the following locations: https://github.com/boschglobal/locator_ros_bridge/blob/3f1f2d6c4a334942bac712fd4db1185734b11295/bosch_locator_bridge/src/locator_bridge_node.cpp#L130 https://github.com/boschglobal/locator_ros_bridge/blob/3f1f2d6c4a334942bac712fd4db1185734b11295/bosch_locator_bridge/src/locator_bridge_node.cpp#L144 https://github.com/boschglobal/locator_ros_bridge/blob/3f1f2d6c4a334942bac712fd4db1185734b11295/bosch_locator_bridge/src/locator_bridge_node.cpp#L158 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 since the bridge node fails to subscribe to the correct laser scan and odometry topics. What’s worse, if an attacker exists, she can even launch man-in-the-middle attacks by first redirecting the bridge node to subscribe to a fake topic e.g. /scan_fake, then sending messages received from /scan to /scan_fake after modifying the contents. In these two cases, the ROKIT Locator will not generate results or even generate wrong localization results. 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/.

kfabian commented 1 year ago

Hi,

thank you very much for your feedback and raising awareness! While I agree that using ROS topic remapping would be the preferable way to modify topic names, I do not think that this adds an additional security issue. In ROS 1 there is no way to prevent someone from publishing or subscribing to a topic or from changing parameter values. Therefore I think a ROS 1 system has to be run in an isolated environment anyhow. If an attacker can change a parameter, she can also publish malicious messages to any topic.