A few days ago, LayerZero, the underlying protocol of the Stargate cross-chain bridge, updated the default transaction verification contract. According to the analysis of the Cobo blockchain security team, this update has fixed a serious loophole in the previous version, which may cause all cross-chains built on LayerZero to The assets of the project are affected.
Stargate FinanceIt is the most eye-catching cross-chain bridge project in recent days. As of the time of publication, the TVL has exceeded 3.5 billion US dollars.
The bottom layer of the Stargate cross-chain bridge is based on LayerZero to achieve cross-chain messaging. The basic principles behind LayerZeros cross-chain messaging are:
Oracle will submit the blockhash and block receiptsRoot on the source chain to the target chain
Relayer will submit the receipt of the transaction on the source chain and the path relationship between the receipt and block receiptsRoot to the target chain. At this time, the transaction verification contract on the target chain will be based on the dependency relationship of Ethereum MPT [1]. Verify the corresponding relationship between the submitted receipt and the receiptsRoot submitted by Oracle
If the verification passes, the receipt is considered a legal receipt and forwarded to the upper layer protocol, triggering subsequent cross-chain asset operations
LayerZero updated the verification contract for cross-chain use on March 28 without any announcement [2]. The Cobo security team found that this update is a fix for the previous major security vulnerability by comparing the code of the original verification contract (MPTValidator) and the new verification contract (MPTValidatorV2) [3].
The patch core code is as follows:
When the original vulnerability code performs MPT verification, it obtains the hashRoot used for the next layer of calculation through the pointer passed in from the outside. Here, solidity underlying add, mload and other assembly instructions are used to obtain hashRoot from proofBytes. Since there is no limit to the length of the pointer within the length of proofBytes, an attacker can pass in an out-of-bounds pointer to make the contract read data other than proofBytes as the next layer hashRoot. In this way, there is the possibility of forging the hashRoot, which further leads to the fact that the forged transaction receipt can pass the MPT verification. The ultimate consequence is that, under the premise that the Oracle is completely trusted, the Relayer can still unilaterally attack the cross-chain protocol by forging the receipt data, breaking the previous security assumption of LayerZero.
The Oracle of the current LayerZero protocol is a contract similar to multi-signature. After two of the three admins submit the same data, the data will be considered valid. However, the Relayer is controlled by a single-signature EOA, and any Relayer can submit attack data to complete all attack processes.
The patched code uses the incoming path and uses the safeGetItemByIndex function to obtain the hashRoot of the next layer of the MPT, ensuring that the hashRoot exists in the current proofBytes, so that the MPT verification can proceed correctly.
The code that exposed the vulnerability this time is the code of the core MPT transaction verification part of the LayerZero protocol, and is the cornerstone of the normal operation of the entire LayerZero and upper-layer protocols (such as Stargate). Although the LayerZero project team has fixed the current obvious vulnerabilities, the possibility of other exploited vulnerabilities cannot be ruled out. In addition, most of the key contracts of the LayerZero project are currently controlled by EOA, and no multi-signature mechanism or time lock mechanism is adopted. If the private keys of these privileged EOAs are leaked, the assets of all upper-layer protocols may also be affected.
Here, the Cobo blockchain security team reminds investors to pay attention to the risks of new projects, and at the same time calls on the LayerZero project party to conduct an in-depth audit of the contract code and transfer the current EOA-controlled privileges to multi-signature or time-locked contracts as soon as possible. Reduce attack exposure.
Reference：
https://eth.wiki/fundamentals/patricia-tree
https://etherscan.io/tx/0xf4f0495bfed37d4d95b3342ead0962433c7973f240b9b0739faa91e6ccac9d40
https://www.diffchecker.com/RJdDTCx7
