Skip to content

Snapshot signature not including HeadID will allow replay attacks

Moderate
ch1bo published GHSA-gr36-mc6v-72qq Sep 21, 2023

Package

hydra-node

Affected versions

< 0.13.0

Patched versions

0.14.0

Description

Summary

Not including a unique head identifier in the multi-signatures, allows an attacker to replay old signatures to close or contest a head with a wrong or incompatible head state.

Details

In the Hydra HeadV1 protocol, all parties do sign snapshots off-chain. The snapshots themselves only include the new UTxO state and a list of transactions which led to that state. Such a "signed snapshot" can then be used as a certificate $\xi$ to close the head or contest a state of a closed head on the main chain.

For that the close & contest validators do check $\mathsf{MSVerify}(\tilde{k}_H, \mathsf{msg}, \xi) = \mathsf{true}$ where the signed message is $\mathsf{msg} = (\mathsf{cid}, \eta_0, \eta)$ where $\eta = (sn, U^{\#})$.

The current implementation, however, does only sign $\eta$ and neither incorporate $\mathsf{cid}$ nor $\eta_0$ with the following impact:

  • Not sign $\mathsf{cid}$: Signatures of the same participants, but from different heads can be re-used or re-played. (Scope of this advisory)
  • Not sign $\eta_0$: Signatures of an open head can be re-used in case the main chain roll-backs "past open" and a different commit transaction leads to the head opening. (Out of scope, much harder to mount an attack)

The on-chain verification of the snapshot signature is here
The off-chain signing of a snapshot is here where the signable representation decides on the actual bytes signed.

Impact

Not signing and verifying $\mathsf{cid}$ allows an attacker (which must be a participant of this head) to use a snapshot from an old head instance with the same participants to close the head or contest the state with it.

This can lead to an incorrect distribution of value (= value extraction attack; hard, but possible) or prevent the head to finalize because the value available is not consistent with the closed utxo state (= denial of service; easy).

Workaround

Rotate keys between heads so not to re-use keys and not result in the same multi-signature participants.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

CVE ID

CVE-2023-42806

Weaknesses

No CWEs

Credits