Robot Vulnerability Database (RVD)

This repository contains the Robot Vulnerability and Database (RVD), an attempt to register and record robot vulnerabilities and bugs.

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

@article{vilches2019introducing,
  title={Introducing the robot vulnerability database (rvd)},
  author={Vilches, V{'\i}ctor Mayoral and Juan, Lander Usategui San and Dieber, Bernhard and Carbajo, Unai Ayucar and Gil-Uriarte, Endika},
  journal={arXiv preprint arXiv:1912.11299},
  year={2019}
}

As main contributor, Alias Robotics supports and offers robot cybersecurity activities in close collaboration with original robot manufacturers. By no means Alias encourages or promote the unauthorized tampering with running robotic systems. This can cause serious human harm and material damages.

Last updated Sat, 25 Feb 2023 10:07:12 GMT

	Open	Closed	All
Vulnerabilities
Bugs
Others

Vulnerabilities (open)

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

ToC

• ToC
• Concepts
• Sponsored and funded projects
  • ROS 2
    • ROS 2 flaws by package (only open ones)
• Disclosure policy
• CI/CD setup
• Contributing, reporting a vulnerability
• Contact us or send feedback
  • Automatic pings for manufacturers
• Appendices
  • Appendix A: Vulnerabilities, bugs, bugs and more
    • Research on terminology
    • Discussion and interpretation
  • Appendix B: How does RVD relate to CVE, the CVE List and the NVD?
  • Appendix C: Legal disclaimer

Concepts

Each RVD issue (ticket) corresponds with a flaw that is labeled appropriately. The meaning of the most relevant labels or statuses is covered below. Refer to the appendices for definitions on the terminology used:

• : Flaw that remains active or under research.
• : Flaw that is inactive. Reasons for inactivity relate to mitigations, duplicates, erroneous reports or similar.
• : Ticket discarded and removed for the overall count. This label flags invalid or failed reports including tests and related.
• : Duplicated flaw. Might go in combination with invalid but if not, typically, a link to the original ticket is provided.
• : Flaw has a malformed syntax. Refer to the templates for basic guidelines on the right syntax.
• : Mitigated. A link to the corresponding mitigation is required.
• : Indicates that the bug is a quality one instead of a security flaw.
• : Indicates that flaw is an exposure.
• : Indicates that flaw is a bug, a security bug can potentially lead to a vulnerability (Note that this last part corresponds with the definition of a weakness, a bug that may have security implications. However, in an attempt to simplify and for coherence with other databases, bug and weakness terms are used interchangeably).
• : Indicates that flaw is a vulnerability.

For more including the categorization used for flaws refer to RVD's taxonomy

Sponsored and funded projects

ROS

Last updated Sat, 25 Feb 2023 10:07:12 GMT

	Open	Closed	All
ROS Vulnerabilities
ROS Bugs
ROS Others

Severity of ROS Vulnerabilities (open and if available)

ROS 2

Last updated Sat, 25 Feb 2023 10:07:12 GMT

	Open	Closed	All
ROS 2 Vulnerabilities
ROS 2 Bugs
ROS 2 Others

Severity of ROS 2 Vulnerabilities (open and if available)

Disclosure policy

Together with RVD, we propose a coherent diclosure policy adopted first by Alias Robotics. Thee disclosure policy is highly inspired by Google's Project Zero. TL;DR, unless otherwise specified, we adhere to 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.

The maintainers of RVD believe that vulnerability disclosure is a two-way street where both vendors and researchers, must act responsibly. We generally adhere to a 90-day disclosure deadline for new vulnerabilities while other flaws such as simple bugs or bugs could be filed at any point in time (refer to Appendix A for the difference between vulnerabilities, bugs 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.

Each security researcher or group should reserve 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.

CI/CD setup

In an attempt to lower the overall effort to maintain the Robot Vulnerability Database, RVD attempts to make active use of Continuous Integration (CI) and Continuous Deployment (CD) techniques through Github Actions. See our configurations here. Contributions and new ideas to this section are welcome. Please submit a Pull Request with your proposal or enhancement.

Below we list some of the existing capabilities (some deprecated in the current setup) and some tentative ones for future versions:

Beta (>= 0.5)

• Comparison of stack trace before flaw submission to avoid duplicates (perfomed upstream) [deprecated, modern versions of the database include more information of relevance than solely the stack trace on each ticket]
• Markdown parser that conforms with RVD templates [deprecated, moved to YAML format]
• Automatic flaw-syntax evaluation (based on parser), tags tickets as malformed when applicable [deprecated, syntax changed]
• Automatic feedback on flaw-syntax, introduced in tickets directly as a comment [deprecated, syntax changed]

1.x (>= 1.0)

• Discussion on a more formal taxonomy to apply when categorizing flaws (see docs/TAXONOMY.md)
• Definition of a formal schema for RVD coherent to the taxonomy and inspired by prior work
• Automatic re-generation of README.md as summary
• Development of CLI toolset to manage RVD
• Include ID in the title of the ticket as "RVD#ID: ..."
• Automatic review of database in-search for duplicates
• Automatic review of database in-search for malformed tickets, tag them appropriately
  • Automatic feedback on malformations
  • Notify when ticket is malformed and skip it (instead of throwing an error as of now)
  • Consider restrictions on title ("RVD#ID: ...")
• Unify YAML dumps in tickets (e.g. stick to yaml.dump(yaml_document))
• Extend TAXONOMY and language to include 'exploitation-recipe'
• Extend TAXONOMY and language to include product and versions, to simplify CVE submission
• Match both Github labels and YAML fields for selected topics:
  • Vendor/manufacturer
  • Products affected
• Use local cache of tickets for all verbs, instead of polling from database every time
• Develop capabilities to output CVE JSON-compatible tickets
• Security action: Add a first-step towards a security pipeline that performs static analysis on source code

Future

• Security action: Unit, functional and integration tests
• Security action: other (TODO: dep. tracking, dynamic analysis)
• Make a table with versions per product and automatically-mitigate (and close) flaws in older versions that haven't been (auto)detected in newer versions.
• Automatic and periodic review of security advisories "in search" for robot-related vulnerabilities
• Automatic and periodic review of NVD "in search" for robot-related vulnerabilities
• Automatic and periodic review of CVE List "in search" for robot-related vulnerabilities
• CWE ID parser and validation method to conform with official CWE guidelines
• Automatic CWE ID validation mechanism (and feedback) in all tickets. Upgrade flaw-syntax evaluation.
• RVSS parser and validation to conform with RVSSv1.0 spec.
• Define some temporal limits for tickets, if it remains without updates longer than the limit, close automatically
  • Consider closed issues when checking for duplicates and if collisions appear, re-open and indicate so
• Automatic RVSS validation mechanism (and feedback) in all tickets. Upgrade flaw-syntax evaluation.
• schema
  • enforce subsystem policy
  • enforce id policy
  • architectural-location get consistency between platform code and platform-code. Same for application-specific. Also, remove ROS-specific.
  • specificity, enfoce policy and allowed keywords

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 rvd_tools/ folder. If you need some inspiration or ideas to contribute, refer to CI/CD setup.

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 bugs are reported. If you're interested in this service, contact contact[at]aliasrobotics[dot]com.

Cite our work

@article{vilches2019introducing,
  title={Introducing the robot vulnerability database (rvd)},
  author={Mayoral-Vilches, V{'\i}ctor and Juan, Lander Usategui San and Dieber, Bernhard and Carbajo, Unai Ayucar and Gil-Uriarte, Endika},
  journal={arXiv preprint arXiv:1912.11299},
  year={2019}
}

Appendices

Appendix A: Vulnerabilities, weaknesses, bugs and more

Research on terminology

Commonly:

• A 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:

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

Moreover, according to CVE page:

• A vulnerability is a bug in the computational logic (e.g., code) found in software and some hardware components (e.g., firmware) that, when exploited, results in a negative impact to confidentiality, integrity or availability (more here).
• An exposure is a system configuration issue or a mistake in software that allows access to information or capabilities that can be used by a hacker as a stepping-stone into a system or network.

ISO/IEC 27001 defines only vulnerability:

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

Discussion and interpretation

From the definitions above, it seems reasonable to associate use interchangeably bugs and flaws when referring to software issues. In addition, the word weakness seems applicable to any flaw that might turn into a vulnerability however it must be noted that (from the text above) a vulnerability "must be exploited"). Based on this a clear difference can be established classifiying flaws with no potential to be exploitable as bugs and flaws potentially exploitable as vulnerabilities. Ortogonal to this appear exposures which refer to misconfigurations that allows attackers to establish an attack vector in a system.

Beyond pure logic, an additional piece of information that comes out of researching other security databases is that most security-oriented databases do not distinguish between bugs (general bugs) and weaknesses (security bugs).

Based in all of the above, we interpret and make the following assumptions for RVD:

• unless specified, all flaws are "security flaws" (an alternative could be a quality flaw)
• flaw, bug and weakness refer to the same thing and can be used interchangeably
• a bug is a flaw with potential to be exploited (but unconfirmed exploitability) unless specified with the quality label in which case, refers to a general non security-related bug.
• vulnerability is a bug that is exploitable.
• exposure is a configuration error or mistake in software that without leading to exploitation, leaks relevant information that empowers an attacker.

Appendix B: How does RVD relate to CVE, the CVE List and the NVD?

Some definitions:

• Robot Vulnerability Database (RVD) is a database for robot vulnerabilities and bugs that aims to record and categorize flaws that apply to robot and robot components. RVD was created as a community-contributed and open archive of robot security flaws. It was originally created and sponsored by Alias Robotics.
• Common Vulnerabilities and Exposures (CVE) List CVE® is an archive (dictionary according to the official source) of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities. CVE contains vulnerabilities and exposures and is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). It is not a database (see official information). CVE List feeds vulnerability databases (such as the National Vulnerability Database (NVD)) with its entries and also acts as an aggregator of vulnerabilities and exposures reported at NVD.
• U.S. National Vulnerability Database (NVD) is the U.S. government repository of standards based vulnerability management data. It presents an archive with vulnerabilities, each with their corresponding CVE identifiers. NVD gets fed by the CVE List and then builds upon the information included in CVE Entries to provide enhanced information for each entry such as fix information, severity scores, and impact ratings.

RVD does not aim to replace CVE but to complement it for the domain of robotics. RVD aims to become CVE-compatible (see official guidelines for compatibility) by tackling aspects such scope and impact of the flaws (through a proper severity scoring mechanism for robots), information for facilitating mitigation, detailed technical information, etc. For a more detailed discussion, see this ROS Discourse thread.

When compared to other vulnerability databases, RVD aims to differenciate itself by focusing on the following:

• robot specific: RVD aims to focus and capture robot-specific flaws. If a flaw does not end-up applying to a robot or a robot component then it should not be recorded here.
• community-oriented: while RVD is originally sponsored by Alias Robotics, it aims to become community-managed and contributed.
• facilitates reproducing robot flaws: Working with robots is very time consuming. Mitigating a vulnerability or a bug requires one to first reproduce the flaw. This can be extremely time consuming. Not so much providing the fix itself but ensuring that your environment is appropriate. At RVD, each flaw entry should aim to include a field named as reproduction-image. This should correspond with the link to a Docker image that should allow anyone reproduce the flaw easily.
• robot-specific severity scoring: opposed to CVSS which has strong limitations when applied to robotics, RVD uses RVSS, a robot-specific scoring mechanism.

As part of RVD, we encourage security researchers to file CVE Entries and use official CVE identifiers for their reports and discussions at RVD.

Appendix C: Legal disclaimer

ACCESS TO THIS DATABASE (OR PORTIONS THEREOF) AND THE USE OF INFORMATION, MATERIALS, PRODUCTS OR SERVICES PROVIDED THROUGH THIS WEB SITE (OR PORTIONS THEREOF), IS NOT INTENDED, AND IS PROHIBITED, WHERE SUCH ACCESS OR USE VIOLATES APPLICABLE LAWS OR REGULATIONS.

By using or accessing this database you warrant to Alias Robotics S.L. that you will not use this Web site for any purpose that is unlawful or that is prohibited. This product is provided with "no warranties, either express or implied." The information contained is provided "as-is", with "no guarantee of merchantability. In no event will Alias Robotics S.L. be liable for any incidental, indirect, consequential, punitive or special damages of any kind, or any other damages whatsoever, including, without limitation, those resulting from loss of profit, loss of contracts, loss of reputation, goodwill, data, information, income, anticipated savings or business relationships, whether or not Alias Robotics S.L. has been advised of the possibility of such damage, arising out of or in connection with the use of this database or any linked websites."

These Terms of Use are made under Spanish law and this database is operated from Vitoria-Gasteiz, Spain. Access to, or use of, this database site or information, materials, products and/or services on this site may be prohibited by law in certain countries or jurisdictions. You are responsible for compliance with any applicable laws of the country from which you are accessing this site. We make no representation that the information contained herein is appropriate or available for use in any location.

You agree that the courts of Vitoria-Gasteiz, Spain shall have exclusive jurisdiction to resolve any controversy or claim of whatever nature arising out of or relating to use of this site. However, we retain the right to bring legal proceedings in any jurisdiction where we believe that infringement of this agreement is taking place or originating.

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.