Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

In the first two posts they found two vulnerabilities that were already patched in LayerZero. This time, they go through a vulnerability in a different section of code.

When calling an external smart contract, you can specify the amount of gas for the call. When doing this, you can pass in 63/64 of the gas in the call. Why? Because the current smart contract also needs some gas to finish executing! If all the gas was actually passed, there's a chance that the current one would run out of gas. Even with the 63/64 out of gas rule, it's possible to get the 1/64 to be eaten up, which is what this bug will exploit.

LZ has two cross-chain token implementations: ONFT(ERC721) and OFT (ERC20). In the ONFT contract, is implements the specification correctly, including the onERC721Received() function. There is no gas limit on this external call, which means we can eat up a lot of gas.

In the _blockingLzRecieve() function, it will try to store the reason for the revert. However, if we use 63/64 from the other contract (which we can from the onERC721Received() entrypoint) then we will be able to force this to revert which not enough gas.

To freeze an ONFT, a user can bridge a low-value NFT then have a malicious contract there. To unfreeze it, the NFT owner can call forceResumeReceive() to remove the payload from the endpoint. Then, it can be resubmitted for 1.5M gas.

When disclosed to LZ on Immunefi, it was pointed out that all NFT/ONFT payouts were limited to the low range of 1K-10K compared to the 25K-250K range for a high impact normally. The easy way to fix this is to override _safeMint() to pass the remaining gas for the transfer iteration and not 63/64th o f the gas.

The small payout for this bug and the previous 2 bugs being dups really disincentivized further research. To make it worse, it seems that many of the bugs are not fixed within the core contracts, making it very difficult to test issues. On top of this, crosschain things are just difficult to test in general.

The series was an interesting perspective into LayerZero bug bounty program and DoS bugs in weird spots. To me, some of the design decisions, like force removing a bad TX, are interesting for limiting the actual damage on the blockchain. LZ seems to generally have good defense in depth and design features.

Besides this, it seems like LZ has some sketchy fixes and practices for bug bounty. From these readings, I personally wouldn't tackle their bug bounty program for the claimed $15M as it's A) very secure with good design and B) complicated to test with the fixes being all over the place and C) a tad sketch on payouts.