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.
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.
Disabling _whiteListEnabled temporarily renders the control over whitelist collections virtually impossible:
The bridge's management system becomes cluttered with numerous, unrelated collections, making it challenging to manage the whitelist efficiently.
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.
Once _whiteListEnabled is activated, managing whitelists will be practically impossible due to spams.
Manual
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.
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.