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.
Cite this work (BibTeX)
@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) |  |
 |
 |
 |
Robot vulnerabilities by robot component
By robot components, we consider both software and hardware robot components
robot component: ABB WebWare SDKrobot component: DDSrobot component: Universal Robots Controllerrobot component: ABB's Service Boxrobot component: ABB RobView 5robot component: DynamixelSDKrobot component: ABB PickMaster 3robot component: kobukirobot component: ABB CP635 HMIrobot component: ABB WebWare Serverrobot component: navigation2robot component: Alpha 1S android applicationrobot component: ABB Interlink Modulerobot component: ABB RobotStudio 5.6xrobot component: Dynamixelrobot component: FastRTPSrobot component: ABB VSN300 WiFirobot component: VxWorksrobot component: ABB QuickTeachrobot component: V-Sido OSrobot component: ABB RobotStudiorobot component: IRB140's flex pendantrobot component: paparazzirobot component: KUKA KR C4robot component: ABB PC SDKrobot component: moveit2robot component: ABB RobotStudio S4robot component: ABB S4 OPC Serverrobot component: ROSrobot component: IRB140's main computerrobot component: VSN300 WiFi Logger Cardrobot component: ABB Robot Communications Runtimerobot component: ABB PickMaster 5robot component: PX4robot component: shadow-robotrobot component: Ubunturobot component: OP2 Firmwarerobot component: Intel NUCrobot component: Othersrobot component: ABB Test Signal Viewer 1.5robot component: mavrosrobot component: Robotwarerobot component: Ardupilotrobot component: CMS-770robot component: Sawyer Task Editorrobot component: MAVLinkrobot component: ABB IRC5 OPC Serverrobot component: ABB DataManagerrobot component: Visual Componentsrobot component: ROS2robot component: ABB RobotStudio Lite
Robot vulnerabilities by robot
robot: KUKA KR 3 R540robot: xArm7robot: Parrot ANAFIrobot: ER-Onerobot: MiR250robot: Alpha 2robot: ER200robot: Vgorobot: UVDrobot: SDA10frobot: MARArobot: NAOrobot: Spykeerobot: Roviorobot: MiR100robot: ER1000robot: Baxterrobot: DBPOWER U818Arobot: ABB IRB140robot: MiR500robot: Pepperrobot: care-o-botrobot: UR3robot: REEM-Crobot: Sawyerrobot: turtlebotrobot: xArm5 Literobot: ER-Literobot: MiR200robot: xArm6robot: ROS (Jade and before)robot: Raven 2robot: UR5robot: Alpha 1Srobot: MiR1000robot: UR10robot: ER-Flex
Robot vulnerabilities by vendor
vendor: Universal Robotsvendor: Robotiqvendor: Acutronic Roboticsvendor: Robotemi Globalvendor: eProsimavendor: ABBvendor: Parrotvendor: Mobile Industrial Robotsvendor: Rethink Roboticsvendor: Yaskawa Motomanvendor: Visual Componentsvendor: PAL Roboticsvendor: Easy Roboticsvendor: ADLINKvendor: Vecnavendor: Open Roboticsvendor: WowWeevendor: RTIvendor: Robotplusvendor: UFactoryvendor: Canonicalvendor: KUKAvendor: Intelvendor: Fanucvendor: Staüblivendor: Applied Dexterityvendor: Mitsubishi Electricvendor: DBPOWERvendor: Enabled Roboticsvendor: WindRivervendor: Softbank Roboticsvendor: UVD Robotsvendor: Robotisvendor: UBTech Robotics
For more, visit the complete list of reported robot vulnerabilities.
- ToC
- Concepts
- Sponsored and funded projects
- Disclosure policy
- CI/CD setup
- Contributing, reporting a vulnerability
- Contact us or send feedback
- Appendices
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
invalidbut 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
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) |
 |
 |
 |
 |
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) |
 |
 |
 |
 |
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.
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:
- 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
malformedwhen applicable [deprecated, syntax changed] - Automatic feedback on flaw-syntax, introduced in tickets directly as a comment [deprecated, syntax changed]
- 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
- 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
subsystempolicy - enforce
idpolicy -
architectural-locationget consistency betweenplatform codeandplatform-code. Same forapplication-specific. Also, removeROS-specific. -
specificity, enfoce policy and allowed keywords
- enforce
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.
Feel free to contact us if you have any requests of feedaback at contact[at]aliasrobotics[dot]com
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.
@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}
}
- A software
bugis 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
weaknessesare errors (bugs) that can lead to software vulnerabilities. - software
vulnerabilityis 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
vulnerabilityis abugin 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
exposureis 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
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
flawsare "security flaws" (an alternative could be a quality flaw) flaw,bugandweaknessrefer to the same thing and can be used interchangeably- a
bugis a flaw with potential to be exploited (but unconfirmed exploitability) unless specified with thequalitylabel in which case, refers to a general non security-related bug. vulnerabilityis a bug that is exploitable.exposureis a configuration error or mistake in software that without leading to exploitation, leaks relevant information that empowers an attacker.
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.
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.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent