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
{{ message }}
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
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, if the /dialogflow_client/results_topic parameter is changed, the dialogflow_client node may publish the results to a wrong topic, and the user nodes of the dialogflow service cannot receive the results. Moreover, if an attacker exists, she can even manipulate the results by first fooling the dialogflow_client node to publish to a wrong topic like /dialogflow_client/results_fake, and the forward the messages from /dialogflow_client/results_fake to /dialogflow_client/results after changing the contents as she wants. 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,
We notice that you are using topic names from ROS parameters at the following locations:
dialogflow_ros/src/dialogflow_ros/dialogflow_client.py
Line 87 in 764a323
dialogflow_ros/src/dialogflow_ros/dialogflow_client.py
Line 89 in 764a323
dialogflow_ros/src/dialogflow_ros/dialogflow_client.py
Line 90 in 764a323
dialogflow_ros/src/dialogflow_ros/dialogflow_client.py
Line 91 in 764a323
dialogflow_ros/src/dialogflow_ros/dialogflow_client.py
Line 92 in 764a323
dialogflow_ros/scripts/mic_client.py
Line 29 in 764a323
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, if the
/dialogflow_client/results_topic
parameter is changed, the dialogflow_client node may publish the results to a wrong topic, and the user nodes of the dialogflow service cannot receive the results. Moreover, if an attacker exists, she can even manipulate the results by first fooling the dialogflow_client node to publish to a wrong topic like/dialogflow_client/results_fake
, and the forward the messages from/dialogflow_client/results_fake
to/dialogflow_client/results
after changing the contents as she wants. 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: