Neo has released the results of an audit contest conducted by Secure3, a platform that collaborates with security experts to identify and mitigate threats to Web3 protocols.
The Neo Native Bridge, developed by Bane Labs, was reviewed using Secure3 to ensure the integrity and security of asset transfers between Neo N3 and Neo X. The audit focused on the bridge’s two main components: the bridge smart contract and the relayer code.
Bridge contract audit
The audit of the Neo X Bridge Contract uncovered a medium-severity issue concerning token registration and deregistration, which posed a risk of replay attacks. This issue was resolved by modifying the system to prevent the deregistration of token bridges, mitigating the potential risk.
Additionally, the audit identified several low-severity concerns, including the use of safeTransferFrom instead of transferFrom, which could have led to unexpected behavior with certain tokens due to non-standard ERC20 implementations. This issue was addressed by adopting OpenZeppelin’s SafeERC20 library.
Another concern was the use of the ecrecover function, which limited validators to externally owned accounts and was vulnerable to signature malleability, potentially leading to forgery or replay attacks. These issues were either acknowledged for future resolution or fixed by switching to more secure alternatives like OpenZeppelin’s ECDSA.recover function.
Minor informational issues, such as code style inconsistencies and unused errors, were also identified and addressed where necessary.
Bridge relayer audit
The audit of the Neo X Bridge Relayer similarly uncovered several low-severity issues. One issue involved the relayer’s program continuing to run indefinitely in the event of a non-connection-related error, potentially leading to resource exhaustion. This was resolved by ensuring the program exits appropriately in such scenarios. Another concern was the potential for a denial of service attack due to the lack of a timeout in the signature processing function, which was fixed by implementing a timeout mechanism.
The audit also highlighted the insecurity in the signature verification process, where the system did not verify the uniqueness of signatures, allowing possible bypasses. This issue was acknowledged, with plans to address it in future updates. Additionally, the hardcoded threshold for the number of signatures required for relayer operations was identified as a limitation, with a more flexible approach planned for future releases.
Other informational issues, such as improper handling of decrypted accounts, insecure password storage, and the risk of race conditions due to the use of goroutines in loops, were noted. While most of these issues were promptly addressed, some were acknowledged and earmarked for future improvements.
The full reports can be found in the announcement linked below:
