RVD#3317: MAVLink version handshaking allows for an attacker to bypass authentication
vmayoral opened this issue · 5 comments
id: 3317
title: 'RVD#3317: MAVLink version handshaking allows for an attacker to bypass authentication'
type: vulnerability
description: The Micro Air Vehicle Link (MAVLink) protocol presents authentication
mechanisms on its version 2.0 however according to its documentation, in order to
maintain backwards compatibility, GCS and autopilot negotiate the version via the
AUTOPILOT_VERSION message. Since this negotiation depends on the answer,
an attacker may craft packages in a way that hints the autopilot to adopt version
1.0 of MAVLink for the communication. Given the lack of authentication capabilities
in such version of MAVLink (refer to CVE-2020-10282), attackers may use this method
to bypass authentication capabilities and interact with the autopilot directly.
cwe: CWE-288
cve: CVE-2020-10283
keywords:
- MAVLink
- v1.0
- v2.0
- PX4
- Ardupilot
system: MAVLink
vendor: "PX4"
severity:
rvss-score: 8.0
rvss-vector: RVSS:1.0/AV:AN/AC:H/PR:N/UI:N/S:U/Y:T/C:H/I:H/A:H/H:U
severity-description: high
cvss-score: 8.1
cvss-vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
links:
- https://mavlink.io/en/guide/mavlink_version.html#version_handshaking
- https://mavlink.io/en/messages/common.html#AUTOPILOT_VERSION
- https://github.com/aliasrobotics/RVD/issues/3316
flaw:
phase: unknown
specificity: subject-specific
architectural-location: platform code
application: Flying vehicles and/or others using MAVLink protocol.
subsystem: communication
package: N/A
languages: C, C++
date-detected: '2020-06-30'
detected-by: "Victor Mayoral Vilches (Alias Robotics)"
detected-by-method: testing
date-reported: '2020-06-30'
reported-by: "Victor Mayoral Vilches (Alias Robotics)"
reported-by-relationship: security researcher
issue: https://github.com/aliasrobotics/RVD/issues/3317
reproducibility: always
trace: N/A
reproduction: N/A
reproduction-image: N/A
exploitation:
description: Not available at the moment, PoC might be built in the future if resources are available.
exploitation-image: Not available
exploitation-vector: Not available
exploitation-recipe: ''
mitigation:
description: Not available
pull-request: N/A
date-mitigation: null
This vulnerability needs further triaged. It has been produced from my readings of the documentation and source code but now PoC is available at the moment.
Aside from a PoC, and a possible mitigation this looks good to me as is.
Yeap, I don't have bandwith nor resources now for putting together a PoC but I'm somewhat confident this should be feasible. Leaving it as triage
required.
Hopefully we'll get resources to fund further research and work things like this out.
Can you provide details of your PoC? In ArduPilot signing is available, so for this vulnerability to be real you'd need to be able to inject a valid message into a signed MAVLink2 stream, and have it parsed and actioned - without a valid signing key. I'd like to see proof that that is possible - else you should remove ArduPilot from this vulnerability. If you read your own links above, from the MAVLink documentation "If signing is enabled then the vehicle should immediately start sending signed MAVLink 2 on startup".