tanrye / RVD

Robot Vulnerability Database. Community-contributed list of robot vulnerabilities and weaknesses.

Home Page:https://aliasrobotics.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Robot Vulnerability Database (RVD)

This repository contains Alias Robotics' Robot Vulnerability and Database (RVD), an attempt to register and record robot vulnerabilities and weaknesses.

Vulnerabilities are rated according to the Robot Vulnerability Scoring System (RVSS). For a discussion regarding terminology and the difference between robot vulnerabilities, robot weaknesses or robot bugs refer to Appendix A.

Alias Robotics supports hacker-powered robot security in close collaboration with original robot manufacturers. By no means we encourage or promote the unauthorized tampering with running robotic systems. This can cause serious human harm and material damages.

Robot vulnerabilities (and weaknesses)

General summary

Last updated Mon, 21 Oct 2019 07:40:13 GMT

Open Closed All
Vulnerabilities label: vulns_open label: vulns_closed label: vulns
Weaknesses label: weaknesses_open label: weaknesses_closed label: weaknesses
Others label: others_open label: others_closed label: others
Vulnerabilities (open) label: vulns_critical label: vulns_high label: vulns_medium label: vulns_low
Robot vulnerabilities by robot component

By robot components, we consider both software and hardware robot components.

Robot vulnerabilities by robot
Robot vulnerabilities by vendor

For more, visit the complete list of reported robot vulnerabilities.

ROS 2

Last updated Mon, 21 Oct 2019 07:40:13 GMT

Open Closed All
ROS 2 Vulnerabilities label: vulns_open_ros2 label: vulns_closed_ros2 label: vulns_ros2
ROS 2 Weaknesses label: weaknesses_open_ros2 label: weaknesses_closed_ros2 label: weaknesses_ros2
ROS 2 Others label: others_open_ros2 label: others_closed_ros2 label: others_ros2
ROS 2 Vulnerabilities (open) label: vulns_critical_ros2 label: vulns_high_ros2 label: vulns_medium_ros2 label: vulns_low_ros2

ROS 2 flaws by package (only open ones)

label: ros2_package_rcl_action label: ros2_package_rcl label: ros2_package_message_filters label: ros2_package_rclcpp label: ros2_package_tf2_ros label: ros2_package_rclcpp_action label: ros2_package_nav2_util label: ros2_package_image_transport label: ros2_package_nav2_recoveries label: ros2_package_nav2_map_server label: ros2_package_rviz_common label: ros2_package_class_loader label: ros2_package_rviz_default_plugins label: ros2_package_composition label: ros2_package_demo_nodes_cpp label: ros2_package_image_tools label: ros2_package_demo_nodes_cpp_native label: ros2_package_interactive_markers label: ros2_package_logging_demo label: ros2_package_rcl_yaml_param_parser label: ros2_package_nav2_costmap_2d label: ros2_package_rosbag2_transport label: ros2_package_test_rclcpp label: ros2_package_test_security label: ros2_package_test_communication label: ros2_package_octomap-distribution label: ros2_package_geometric_shapes label: ros2_package_intra_process_demo label: ros2_package_rosbag2_converter_default_plugins label: ros2_package_rosbag2_storage_default_plugins label: ros2_package_tlsf_cpp

Disclosure policy

Our disclosure policy is highly inspired by Google's Project Zero. TL;DR, we apply a 90-day disclosure deadline for new vulnerabilities.

This policy is strongly in line with our desire to improve the robotics industry response times to security bugs, but also results in softer landings for bugs marginally over deadline. According to our research, most vendors are ignoring security flaws completely. We call on all researchers to adopt disclosure deadlines in some form, and feel free to use our policy verbatim (we've actually done so, from Google's) if you find our record and reasoning compelling. Creating pressure towards more reasonably-timed fixes will result in smaller windows of opportunity for blackhats to abuse vulnerabilities. Given the direct physical connection with the world that robots have, in our opinion, vulnerability disclosure policies such as ours result in greater security in robotics and an overall improved safety. A security-first approach is a must to ensure safe robotic operations.

Alias Robotics believes that vulnerability disclosure is a two-way street where both vendors and researchers, must act responsibly. We adhere to a 90-day disclosure deadline for new vulnerabilities while other flaws such as simple bugs or weaknesses could be filed at any point in time (refer to Appendix A for the difference between vulnerabilities, weaknesses and bugs). We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix.

Similar to Google's policy, we want to acknowledge that the deadline can vary in the following ways:

  • If a deadline is due to expire on a weekend or public holiday, the deadline will be moved to the next normal work day.

  • Before the 90-day deadline has expired, if a vendor lets us know that a patch is scheduled for release on a specific day that will fall within 14 days following the deadline, we will delay the public disclosure until the availability of the patch.

  • When we observe a previously unknown and unpatched vulnerability in software under active exploitation (a “0day”), we believe that more urgent action—within 7 days—is appropriate. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more devices or accounts will be compromised. Seven days is an aggressive timeline and may be too short for some vendors to update their products, but it should be enough time to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the vendor for more information. As a result, after 7 days have elapsed without a patch or advisory, we will support researchers making details available so that users can take steps to protect themselves.

Alias Robotics reserves the right to bring deadlines forwards or backwards based on extreme circumstances. We remain committed to treating all vendors strictly equally and we expect to be held to the same standard.

Contributing, reporting a vulnerability

Vulnerabilities are community-contributed. If you believe you have discovered a vulnerability in a robot or robot component (either software or hardware), obtain public acknowledgement by submitting a vulnerability while providing prove of it. Reports can be submitted in the form of an issue.

If you wish to contribute to the RVD repository's content, please note that this document (README.md) is generated automatically. Submit the corresponding PRs by looking at the scripts/ folder.

Contact us or send feedback

Feel free to contact us if you have any requests of feedaback at contact[at]aliasrobotics[dot]com

Automatic pings for manufacturers

By default, new vulnerabilities are reported to manufacturers and/or open source projects however other flaws aren't. Alias Robotics can inform manufacturers directly when weaknesses are reported. If you're interested in this service, contact contact[at]aliasrobotics[dot]com.

Appendices

Appendix A: Vulnerabilities, weaknesses, bugs and more

Discussion

Commonly:

  • A (robot) software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

According to CWE:

  • (robot) software weaknesses are errors (bugs?) that can lead to software vulnerabilities.
  • (robot) software vulnerability is a mistake in software that can be directly used by a hacker to gain access to a system or network.

ISO/IEC 27001 defines only vulnerability:

  • (robot) vulnerability: weakness of an asset or control that can be exploited by one or more threats

Based on all this, we'll assume that both "weakness" and "bug" refer to the same thing, an error in code that might turn into a "vulnerability" if exploitable. To establish some clear relationship:

 bugs == weaknesses
 weakness -> vulnerability <-> weakness is exploitable

Finally, we consider that a (robot) flaw is a generic term to refer too any of the above concepts.


rosin_logo

Supported by ROSIN - ROS-Industrial Quality-Assured Robot Software Components. More information: rosin-project.eu

eu_flag

This repository was partly funded by ROSIN RedROS2-I FTP which received funding from the European Union’s Horizon 2020 research and innovation programme under the project ROSIN with the grant agreement No 732287.

About

Robot Vulnerability Database. Community-contributed list of robot vulnerabilities and weaknesses.

https://aliasrobotics.com


Languages

Language:Python 100.0%