NFTBridge
60,000 USDC
View results
Submission Details
Severity: low
Invalid

Management of Whitelist Collections Should Be Exclusively Controlled Through the Owner's `whiteList` Function.

Relevant GitHub Links

https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/Bridge.sol#L192

Summary

The current implementation inadvertently permits any user to register new collections in _whiteList and collections by withdrawing tokens that is transferred when _whiteListEnabled is set to false, despite the intended restriction to only allow the owner to manage these collections. This oversight will introduce a significant management efforts and security risk as well.

Vulnerability Details

The system utilizes two key mechanisms for managing whitelisted collections: _whiteListEnabled and _whiteList. The _whiteListEnabled flag determines whether the bridge is accessible for general NFT transfers or limited to whitelisted collections only. When _whiteListEnabled flag is enabled, _whiteList serves as a registry of collections' whitelist statuses.

A critical flaw emerges when collections are transferred through the bridge while _whiteListEnabled is deactivated (false). During this period, newly withdrawn collections are added to both _collections and _whiteList, contrary to the intended design. This misconfiguration allows any user to indirectly influence the whitelist by withdrawing collections, leading to unauthorized collections being whitelisted within Bridge.sol. This situation complicates the owner's ability to manage the whitelist effectively. Furthermore, the absence of a mechanism to remove entries from _collections exacerbates the issue, as it leads to an overloaded whiteList operation due to irrelevant collections.

Attack Scenario

Disabling _whiteListEnabled temporarily renders the control over whitelist collections virtually impossible:

  1. The bridge's management system becomes cluttered with numerous, unrelated collections, making it challenging to manage the whitelist efficiently.

  2. Even after the owner meticulously reviews and adjusts the whitelisted collections, attackers can exploit the system by delaying withdrawals until _whiteListEnabled is reactivated. This forces the owner into a continuous cycle of reviewing and correcting the whitelist, which is practically unfeasible.

Impact

Once _whiteListEnabled is activated, managing whitelists will be practically impossible due to spams.

Tools Used

Manual

Recommendations

To address this vulnerability, the _whiteListCollection call should be eliminated in withdrawTokens. The management of collections and _whiteList should be strictly reserved for the owner, utilizing the whiteList function.

if (collectionL1 == address(0x0)) {
if (ctype == CollectionType.ERC721) {
collectionL1 = _deployERC721Bridgeable(
req.name,
req.symbol,
req.collectionL2,
req.hash
);
- // update whitelist if needed
- _whiteListCollection(collectionL1, true);
} else {
revert NotSupportedYetError();
}
}
Updates

Lead Judging Commences

n0kto Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Design choice
Assigned finding tags:

Informational / Gas

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.