ABI encodePacked Collision
Severity: High
Confidence: High
Description:
During the audit of the smart contract, we identified a potential vulnerability related to the usage of abi.encodePacked which can lead to ABI encodePacked collision. The contract contains the following code:
address predictedAddress = address(
uint160(
uint256(
keccak256(
abi.encodePacked(
bytes1(0xff),
deployer,
bytes32(salt), // Explicitly convert salt to bytes32
keccak256(
abi.encode(
byteCode,
abi.encode(
price,
tokenContract,
buyer,
seller,
arbiter,
arbiterFee
)
)
)
)
)
)
)
);
Exploit Scenario:
The abi.encodePacked function is used to concatenate data in a non-standard way, and it can lead to collisions when combining different types of data. In a specific scenario, where a function like get_hash_for_signature is used to generate an ID based on some input parameters, an attacker can intentionally create a collision with a different set of inputs, leading to unexpected behavior or even compromising the system.
Recommendation:
To mitigate the risk of ABI encodePacked collision, we strongly recommend using abi.encode instead of abi.encodePacked. The abi.encode function uses a standardized way of encoding data, which ensures that there are no collisions and reduces the risk of unexpected behavior.
By using abi.encode, you ensure that the data is properly encoded without any risk of collisions. This will improve the security of the smart contract and reduce the chances of potential vulnerabilities.
It is crucial to thoroughly test the revised code to ensure its correctness and security. Additionally, we advise performing further comprehensive testing, including edge cases and scenarios with different input values, to verify the robustness of the smart contract.
Tools Used:
1.)Slither
2.)Echidna
3.)Manticore
4.)solhint and solium
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.