ArkProject: NFT Bridge

Summary

The requestDeserialize function in Protocol.sol does not ensure that L1 addresses are smaller than 20 bytes. This oversight can lead to vulnerabilities where incorrect or malicious addresses may be processed.

Vulnerability Details

In the requestDeserialize function, L1 addresses are deserialized using the following lines of code:

However, there is no check to ensure that the addresses derived from the uint256 values in the buffer are valid Ethereum addresses, which must be 20 bytes or less. The current implementation directly converts the uint256 value to an address type by casting it to uint160. This conversion truncates the uint256 to the lower 160 bits, which might result in an incorrect or unintended address if the original uint256 value is larger than 160 bits.

Impact

If the input buffer contains a uint256 value greater than 160 bits, the resulting address could be incorrect. This could lead to unintended behavior, such as transferring funds to an incorrect address, losing assets, or allowing a malicious actor to exploit the protocol by manipulating the address values in the buffer. The severity of the impact depends on how the protocol uses these addresses, but in the worst-case scenario, it could result in a complete loss of NFTs.

Recommendations

To mitigate this issue, the protocol should include a check to ensure that the L1 addresses being deserialized are valid Ethereum addresses, specifically that they are 20 bytes or smaller. One approach could be to verify that the upper 96 bits of the uint256 value are zero before casting it to an address. For example:

This will ensure that only valid Ethereum addresses are used, preventing potential vulnerabilities arising from improper address deserialization.