Lines of code
<https://github.com/code-423n4/2023-04-ens/blob/main/contracts/dnssec-oracle/algorithms/ModexpPrecompile.sol#L7&gt;

Vulnerability details

Impact

This vulnerability to cause unexpected behavior or even a denial-of-service attack on a contract that uses the RSAVerify library on (<https://github.com/code-423n4/2023-04-ens/blob/main/contracts/dnssec-oracle/algorithms/RSAVerify.sol&gt;).

The vulnerable code is at:
<https://github.com/code-423n4/2023-04-ens/blob/main/contracts/dnssec-oracle/algorithms/ModexpPrecompile.sol&gt;

Integer overflow in modexp function in ModexpPrecompile does not perform any input validation on the lengths of base, exponent, and modulus. This could result in an integer overflow if any of these values are too large, leading to unexpected behavior or even a denial-of-service attack.

The integer overflow to occur if any of the base, exponent, or modulus parameters are too large. The uint256 type can store integers up to 2^256-1, which is an extremely large number, but if any of these parameters exceed this value, an integer overflow can occur. The ModexpPrecompile.modexp function does not perform any input validation on the lengths of these parameters, so it is possible for an attacker to craft a malicious input that causes an integer overflow and triggers unexpected behavior or even a denial-of-service attack. For example, an attacker could craft a base parameter that is a very large number, causing an integer overflow when combined with a large exponent parameter. This could result in a very large number being passed to the modulus parameter, causing an out-of-gas error or even crashing the Ethereum node processing the transaction.

integer overflow occurs in the ModexpPrecompile.modexp function due to large input parameters, it could lead to unexpected behavior or even a denial-of-service (DoS) attack. The impact of a DoS attack could be significant, as it could prevent legitimate users from interacting with the contract and potentially cause financial losses. The unexpected behavior could also lead to incorrect results, which could also have negative consequences depending on the specific context in which the function is used.

Proof of Concept

In this POC i will demonstrates how an attacker can exploit the integer overflow vulnerability in the ModexpPrecompile.modexp function:

pragma solidity ^0.8.4;

import “./RSAVerify.sol”;

contract RSAExploit {
// Set the maximum length of base, exponent, and modulus to the maximum uint256 value
bytes32 constant MAX_LENGTH = bytes32(uint256(-1));

// The RSA public modulus and exponent
bytes public N;
bytes public E;

// The malicious input that will trigger an integer overflow
bytes public maliciousInput;

constructor() {
    // Set the public modulus and exponent
    N = hex"db0442b4ca4e04bf237d88e928b5a294c5f5d832680d3b3c4b29a4b4f41f9d823d88e29b50185a1c33a46d2f640005118a8cc41f68cc739e1ac9a4497dca0de";
    E = hex"010001";

    // Create a malicious input that will cause an integer overflow
    maliciousInput = abi.encodePacked(
        MAX_LENGTH,
        MAX_LENGTH,
        MAX_LENGTH,
        hex"00",
        hex"00",
        hex"00"
    );
}

// The malicious function that triggers the integer overflow
function triggerOverflow() public {
    // Call the rsarecover function with the malicious input
    RSAVerify.rsarecover(N, E, maliciousInput);
}

}

In this POC, we set the maximum length of base, exponent, and modulus to the maximum uint256 value, which will cause an integer overflow when these values are encoded as uint256 in the ModexpPrecompile.modexp function. We then create a malicious input that triggers the integer overflow and call the rsarecover function with this input in the triggerOverflow function.

An attacker can use this vulnerability to cause unexpected behavior or even a denial-of-service attack on a contract that uses the RSAVerify library. To mitigate this vulnerability, input validation should be added to the ModexpPrecompile.modexp function to ensure that the lengths of the input parameters do not exceed the maximum allowed values.

Tools Used

Recommended Mitigation Steps

To mitigate the risk of integer overflow attacks in the modexp function of the ModexpPrecompile library, you should perform input validation on the lengths of the base, exponent, and modulus parameters before executing the modexp function.

One way to perform input validation is to limit the maximum length of each parameter to a reasonable value, such as a number that is less than or equal to 2^256-1, which is the maximum value that can be stored in a uint256 variable.

Here’s an updated version of the modexp function that performs input validation:

function modexp(bytes memory base, bytes memory exponent, bytes memory modulus) internal view returns (bool success, bytes memory output) {
    require(base.length <= MAX_LEN, "Base too long");
    require(exponent.length <= MAX_LEN, "Exponent too long");
    require(modulus.length <= MAX_LEN, "Modulus too long");

    bytes memory input = abi.encodePacked(
        uint256(base.length),
        uint256(exponent.length),
        uint256(modulus.length),
        base,
        exponent,
        modulus
    );

    output = new bytes(modulus.length);

    assembly {
        success := staticcall(
            gas(),
            5,
            add(input, 32),
            mload(input),
            add(output, 32),
            mload(modulus)
        )
    }
}

In this updated version, the MAX_LEN constant can be set to a value that limits the maximum length of each parameter. If any of the parameters exceed this limit, the function will revert with an error message.

---

The text was updated successfully, but these errors were encountered:

All reactions