The depositTokens function in the Solidity and Cairo contracts uses a salt value to generate a hash, raising a potential risk of collision.
In the depositTokens function, the use of a salt value to generate a hash raises a potential risk of collision, especially when using a combination of collection and salt for hash generation. While the likelihood of such a collision is low, it could lead to unintended consequences such as the failure of contract deployment
Locations:
https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/Bridge.sol#L79
https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/starknet/src/bridge.cairo#L450
If a hash collision occurs, it could lead to significant issues such as the failure of contract deployment. Although the probability of such an event is low, the impact could be medium.
Manual code review
Instead of passing salt as parameter, consider using a counter or a unique nonce to ensure that each generated hash is unique. This approach reduces the risk of collisions and provides a more predictable mechanism for hash generation.
If the salt is necessary, ensure it is generated in a manner that significantly reduces the chance of reuse or collision. For example, incorporating additional unique identifiers, such as timestamps
Implement checks to verify that a newly generated hash does not collide with any existing hashes
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.