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)
- Disclosure policy
- Contributing, reporting a vulnerability
- Contact us or send feedback
- Appendices
Robot vulnerabilities (and weaknesses)
General summary
Last updated Mon, 21 Oct 2019 07:40:13 GMT
Open | Closed | All | |
---|---|---|---|
Vulnerabilities | |||
Weaknesses | |||
Others |
Vulnerabilities (open) |
Robot vulnerabilities by robot component
By robot components, we consider both software and hardware robot components.
-
Community robot components
-
Vendor-specific robot components
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 |
|||
ROS 2 Weaknesses |
|||
ROS 2 Others |
ROS 2 Vulnerabilities (open) |
open
ones)
ROS 2 flaws by package (only
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
- 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.
Supported by ROSIN - ROS-Industrial Quality-Assured Robot Software Components. More information: rosin-project.eu
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.