The contract uses the supportsInterface()
function to check whether another contract supports a specific interface. However, if the contract being queried does not implement the ERC-165 standard or if it has been maliciously designed to revert when supportsInterface()
is called, this check could cause the transaction to fail. This could result in a failed interaction, disrupting the normal operation of the contract and potentially consuming all available gas.
The supportsInterface()
function, part of the ERC-165 standard, is commonly used to verify if a contract implements a particular interface. However, it is important to verify that the contract being queried correctly follows the ERC-165 standard. If a contract does not implement ERC-165 or has been designed maliciously to revert on this check, the call to supportsInterface()
will fail.
Line of the Affected Code
This line could lead to a reversion or high gas consumption if the called contract does not properly handle the supportsInterface()
call or if the contract is malicious. The failure to handle this case securely exposes the contract to potential service disruption or malicious exploitation.
If supportsInterface()
is called on a contract that does not correctly implement the ERC-165 standard, there is a risk that the call may revert, causing disruptions in contract execution. A malicious actor could exploit this by deploying a contract that behaves unexpectedly, consuming excessive gas or causing the calling contract to fail. This vulnerability can lead to denial of service (DoS), where legitimate transactions fail or interactions with other contracts are interrupted.
The likelihood of exploitation depends on the level of control an attacker has over the contract's interactions. If the contract interacts with unknown or user-controlled contracts and relies on supportsInterface()
to verify compliance with ERC-165, an attacker could deploy a malicious contract specifically designed to revert the call or consume excessive gas.
If the affected contract is widely used or interacts with many external contracts, the chances of encountering such an issue increase. However, if the contract interacts only with trusted or verified contracts, the risk is lower. Still, the possibility of malicious contracts in the ecosystem makes this a non-negligible concern.
The most harmful consequence of this vulnerability is a denial of service (DoS) attack, where an attacker can deploy a contract that either does not implement ERC-165 or intentionally causes a revert when supportsInterface()
is called. This can disrupt normal operations and cause failures in critical parts of the contract, leading to:
Disruption of contract functionality: Other contracts or functions that rely on the correct response from supportsInterface()
could fail, potentially stalling operations or causing transactions to revert.
Wasted gas consumption: If the call to supportsInterface()
causes a revert or high gas consumption, it can waste the user's gas, leading to a poor user experience or unnecessary costs.
Malicious exploitation: An attacker can deploy a contract designed to fail the supportsInterface()
check, leading to failures in calls that rely on interface validation, potentially bypassing checks or causing delays in execution.
Impairment of contract interactions: In decentralized systems, interactions between smart contracts are common, and this vulnerability can impair the ability to verify compliance with required standards, leading to integration failures between interacting contracts.
Manual Review
To mitigate the risk of reversion and excessive gas consumption when using supportsInterface(), it is essential to ensure that the contract being queried follows the ERC-165 standard. A safe approach is to use OpenZeppelin's ERC165Checker utility, which provides a safe and efficient way to check whether a contract supports a given interface without risking reversion.
By utilizing ERC165Checker.supportsInterface(), the contract can safely check for interface support and avoid reverts or excessive gas consumption. This provides a more secure interaction with other contracts and prevents unexpected failures.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.