Project

Summary

The NativeMetaTransaction contract is vulnerable to signature malleability, where an attacker can modify the sigS value of a valid signature without invalidating it. This allows the attacker to bypass nonce checks and replay the same transaction multiple times, potentially leading to unauthorized re-execution of transactions.

Vulnerability Details

The verify function in NativeMetaTransaction does not verify whether the sigS component of the signature is in the lower half of the secp256k1 curve. In elliptic curve cryptography, each valid signature has two possible representations for the s value, one in the lower half and one in the upper half of the curve. Failing to restrict sigS to the lower half allows an attacker to modify the signature while keeping it valid. This opens the protocol to signature malleability, where the altered signature is considered different from the original, even though it represents the same transaction.

https://github.com/Cyfrin/2024-11-one-world/blob/main/contracts/meta-transaction/NativeMetaTransaction.sol#L90-L106

1. The attacker observes a valid meta-transaction with a signature (r, s, v).

2. They modify the sigS value, flipping it to its counterpart in the upper half of the curve.

3. The attacker submits this modified signature, which the contract treats as a new, valid signature.

4. The contract re-executes the meta-transaction, bypassing the nonce check and allowing the attacker to replay the same transaction.

Impact

Critical — Signature malleability could allow attackers to:

• Replay transactions: Malicious actors could re-execute the same transaction multiple times, causing unintended and unauthorized outcomes, such as repeated fund transfers or contract calls.

• Bypass nonce mechanisms: The nonce system, meant to prevent replay attacks, is rendered ineffective, as each modified signature is treated as unique.

Tools Used

Manual Reivew

Recommendations

To prevent signature malleability, the verify function should be updated to include a check that ensures the sigS value is in the lower half of the secp256k1 curve. This is a standard practice in Ethereum to avoid malleability exploits.

Here’s the required fix:

This check guarantees that only signatures with s values in the lower half of the curve are accepted, preventing attackers from submitting modified signatures and protecting the contract from replay attacks.