Skip to content

Mithril certificate chain could be manipulated by an adversarial signer

Moderate
jpraynaud published GHSA-724h-fpm5-4qvr Feb 14, 2025

Package

Mithril client CLI (Mithril network)

Affected versions

< 0.11.0

Patched versions

0.11.0
Mithril client WASM (Mithril network)
< 0.8.1
0.8.1
Mithril client library (Mithril network)
< 0.11.1
0.11.1

Description

Impact

The Mithril certificate chain

The Mithril certificate chain is the mechanism that allows Mithril clients to verify the authenticity of Mithril certificates.

The aggregate verification key is the compressed Merkelized representation of the Mithril stake distribution used to create a multi-sign changes at every epoch of the Cardano chain.
The protocol parameters are the cryptographic parameters used by the Mithril signers and Mithril aggregators to jointly create Mithril multi-signatures.

A Mithril certificate is valid if and only if it contains a valid Mithril multi-signature and the multi-signature is verified with an aggregate verification key that was signed in the previous epoch by a valid multi-signature or a valid genesis signature.

The verification of the Mithril multi-signature is done with both an aggregate verification key and protocol parameters.

Manipulation of the Mithril certificate chain

We have identified a scenario which could allow an adversarial signer which is registered in the Mithril stake distribution of the current epoch to create an a tampered certificate which would not be detected by the current verification algorithm.

In this scenario, a valid single signature could be created by manipulating the phi_f parameter (or k or m parameters) so that this signature wins enough lotteries to reach the quorum and allow the creation of a valid multi-signature with the correct aggregate verification key for the current epoch. The forged certificate would carry a valid aggregate verification key, a valid multi-signature but tampered protocol parameters and it would not be detected as tampered as the protocol parameters are not certified by the certificate chain.

Attack scenarios

Today, there exists only one aggregator in a Mithril network (which is operated by IOG and therefore assumed honest).

  • A first scenario is if a Mithril client is victim of a DNS spoofing attack: in that case it could download an adversary certificate chain instead of an authentic one produced by the honest aggregator.
  • A second scenario is if the Mithril aggregator is compromised and its certificate chain is manipulated in order to be replaced by an adversary chain

In the future, the Mithril networks will be further decentralized and multiple aggregators will be able to operate independently. In that case the risk would be higher as no DNS spoofing attack would be needed in order to serve an adversary certificate chain to a Mithril client.

Patches

  • The Mithril signer has been fixed with version 0.2.200 and is deployed on 100% of the Mithril networks.
  • The Mithril aggregator has been fixed with version 0.5.83 and is deployed on 100% of the Mithril networks.
  • The Mithril client library has been fixed with version 0.11.1, previous versions must not be used anymore.
  • The Mithril client CLI has been fixed with version 0.11.0, previous versions must not be used anymore.
  • The Mithril client WASM has been fixed with version 0.8.1, previous versions must not be used anymore.

Workarounds

There is actually no workaround available except making sure the multi-signature is signed by enough signers (having only one or too few signers, or having too few stake involved would be an evidence of manipulation).

References

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
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

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:H/PR:L/UI:N/S:U/C:N/I:H/A:N

CVE ID

No known CVE

Weaknesses

No CWEs

Credits