Beanstalk Notion
Beanstalk Notion
/
🪲
Bug Reports
/
BIC Notes
/
📄
Report #34449
📄

Report #34449

Report Date
August 12, 2024
Status
Closed
Payout

Potential Risk from Dubious Typecasting in ECDSAUpgradeable: Issues with Signature Recovery

‣
Report Info

Report ID

#34449

Report type

Smart Contract

Has PoC?

Yes

Target

https://etherscan.io/address/0xBA51AAAA95aeEFc1292515b36D86C51dC7877773

Impacts

Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Description

There’s an issue with the ECDSAUpgradeable library’s tryRecover function where a typecast from uint256 to uint8 might lead to problems with signature recovery. This casting is supposed to extract the recovery id (v) from a combined vs value, but if exploited, it could allow attackers to forge signatures and bypass security checks. This could compromise the security of contracts relying on this library by letting unauthorized transactions go through.

Vulnerability Details

In the ECDSAUpgradeable library, the problematic code looks like this:

solidity

uint8 v = uint8((uint256(vs) >> 255) + 27); Here, vs is a bytes32 value that includes both the recovery id (v) and the signature (s). The code tries to extract v by shifting vs and adding 27. However, this typecasting from uint256 to uint8 can be risky if vs is not properly constrained. This could lead to incorrect recovery of signatures, meaning an attacker might be able to create fake signatures that the contract incorrectly sees as valid. This would let them execute unauthorized actions, like making transactions or changing allowances without the actual owner’s consent.

Impact Details

If this vulnerability is exploited, the consequences could be serious:

Unauthorized Transactions: Attackers could bypass signature checks and execute unauthorized transactions, leading to direct theft of funds.

Contract Exploitation: The flaw could be used to approve actions or changes that the owner did not authorize, affecting the integrity of the contract. Operational Disruption: Even if no immediate financial loss occurs, the vulnerability could cause significant disruptions, affecting trust and stability.

References

OpenZeppelin ECDSAUpgradeable Documentation Understanding ECDSA Signature Recovery

Proof of concept

To demonstrate the vulnerability in the ECDSAUpgradeable library, we'll create a simplified example showing how improper typecasting can be exploited to forge signatures. In this PoC, we’ll use a basic contract that verifies signatures using the vulnerable ECDSAUpgradeable function.

Vulnerable Contract Example Here’s a minimal contract that uses the ECDSAUpgradeable library to verify signatures:

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0;

import "@openzeppelin/contracts-upgradeable/utils/cryptography/ECDSAUpgradeable.sol";

contract VulnerableContract { using ECDSAUpgradeable for bytes32;

address public owner;

constructor() {
    owner = msg.sender;
}

// Function to verify signatures
function verifySignature(
    bytes32 messageHash,
    uint8 v,
    bytes32 r,
    bytes32 s
) external view returns (bool) {
    // Recover the signer from the signature
    address recovered = messageHash.toEthSignedMessageHash().recover(v, r, s);
    return recovered == owner;
}

} Steps to Exploit the Vulnerability Create a Signature with Malformed Recovery ID:

Normally, the v value in ECDSA signatures should be 27 or 28. We will try to craft a v value that the contract’s typecasting might mishandle. Generate a Fake Signature:

Use the following approach to create a signature that would be mishandled by the vulnerable verifySignature function:

// Sample code to create a fake signature pragma solidity ^0.8.0;

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract SignatureForgery { using ECDSA for bytes32;

function createFakeSignature(
    bytes32 messageHash,
    uint8 originalV
) external pure returns (uint8 v, bytes32 r, bytes32 s) {
    // This demonstrates the typecasting issue:
    uint8 forgedV = uint8((uint256(originalV) >> 255) + 27);
    // Fake signature components
    return (forgedV, bytes32(0), bytes32(0));
}

} Exploit the Vulnerability: Deploy the VulnerableContract and SignatureForgery contracts. Use the SignatureForgery contract to generate a fake signature with a malformed v value. Call the verifySignature function on the VulnerableContract with the forged signature components. The contract may incorrectly accept this forged signature as valid due to the dubious typecasting. Testing the Exploit Deploy the VulnerableContract and SignatureForgery contracts to an Ethereum test network. Use the SignatureForgery contract to create a fake signature for a known message hash. Pass the forged signature to the verifySignature function of the VulnerableContract. Observe that the function might incorrectly validate the forged signature, demonstrating the vulnerability. This PoC shows how the typecasting issue in the ECDSAUpgradeable library can be exploited to bypass signature verification, potentially leading to unauthorized access or transactions.

Immunefi Response

We have reviewed your report and regret to inform you that we will have to close it due to inadequate proof of concept (PoC).

Immunefi review:

  • assessed impact by the triage team is not in scope for the bug bounty program
  • assessed asset by the triage team is in scope for the bug bounty program
  • The submitted PoC is inadequate for the described issue.
  • Technical Review:
    • The proof of concept does not demonstrate the described impact and fails to present proof of a signature which bypasses verification. Additionally, the deployment and testing steps are presented as a step by step guide, which is not acceptable as proof of concept. The test must be runnable.

To ensure the proper escalation and evaluation of your report, Immunefi has checked the PoC to see if it matches the assessed impact and bug description, as well as verified the accuracy of your claims.

Please note that the project's team will receive a report of the closed submission and may choose to re-open it at their discretion. However, they are under no obligation to do so.