Moonbeam, Astar, And Acala Library Truncation Bugfix Review — $1m Payout

On June 27th, whitehat pwning.eth submitted a critical bug report that impacted the Polkadot ecosystem via Immunefi, demonstrating the possibility of minting valid but depegged wrapped tokens.

The bug, which was found within Frontier — the Substrate pallet that provides core Ethereum compatibility features within the Polkadot ecosystem–impacted Moonbeam, Astar Network, and Acala.

The estimated potential damage from the vulnerability amounted to approximately $200m across the three projects, which was swiftly prevented due to the whitehat’s brilliant disclosure.

In other words, a major vulnerability that would have made headlines if exploited, was successfully reported and patched, owing to the collaborative efforts of everyone involved in this report.

After receiving the report, Moonbeam quickly released an upgrade that patched the vulnerability, and the whitehat was awarded $1 million for his find. Parity, the developer of the Frontier Library, decided to contribute $250,000 towards the $1 million reward amount, despite not having any bug bounty with Immunefi.

We want to take the time to congratulate Parity for going above and beyond to show their commitment to the security and well-being of the crypto ecosystem.

This report from pwning.eth is one of the most detailed and in-depth vulnerability report cases to exist in blockchain history, and hundreds of millions of user funds were saved as a result.

It’s a major success story for the blockchain space.

You can read pwning.eth’s blog post about his responsible disclosure here.

Almost all blockchain networks feature native assets as well as tokens that are ERC20-like, especially when those blockchains are EVM-compatible. In Ethereum itself, we have Ethereum and Wrapped Ethereum, Bitcoin and Wrapped Bitcoin, and many more. On Moonbeam, we have native tokens like MOVR and GLMR and their wrapped counterparts, like WMOVR and WGLRM. Likewise on Astar, there is Astar and Wrapped Astar.

The reason behind wrapping native coins as tokens is to be able to integrate with more DeFi protocols. It is all about interoperability within a DeFi ecosystem and allowing users to use the same token across a multitude of dApps without worrying about buying or selling native tokens in order to use ones that the application supports.

Wrapped native tokens are undoubtedly one of the pillars of DeFi. They store huge amounts of native funds and are used in a plethora of dApps from lending applications, DEXes, and many more. If somebody were able to find a bug in the code of one of these tokens, it would be devastating to the whole ecosystem.

Just imagine if somebody had discovered a bug in WETH.

That’s exactly what happened on Moonbeam, Astar Network, and Acala.

They were all vulnerable to a bug that could have allowed malicious users to mint wrapped native tokens!

What was the bug?

The security vulnerability that pwning.eth discovered was found in the Frontier Library, which is Substrate’s Ethereum compatibility layer. It allows you to run unmodified Ethereum DApps. The central issue was with how Frontier handled low-level EVM events.

In the above code snippet, we notice in transfer that the msg.value is reduced (or truncated) from 256 bits to 128 bits. This seemingly innocuous oversight might result in serious discrepancy between the runtime and the EVM environment.

What is truncation? In simplest terms, truncation means to cut off a portion of the number. If we do decimal truncation of 9.8, we would cut-off 0.8 and we would be left with 9. In bit truncation, we truncate the higher bits of a number. For example, truncating a 32 bit number to 16 bits would result in higher-end bits being cut-off and only the lower 16 bits staying.

65539 (32 bit) to 16 bit would result in the number 3. Why?

65539 is 10000000000000011 in binary. As it only takes 17 bits to hold that number, we only leave with the lower 16 bits (counting from right), and we are left with 0000000000000011, which is 3.

What does this all mean in the context of the bug? Smart contracts believe that the huge 256 bit msg.value is valid, although the actual transfer never happens, as the truncated value will be zero, even though we passed in msg.value 2¹²⁸.

In reality, we won’t be transferring any native tokens, due to this error. However, smart contracts that accept msg.value as though it were in 256 bit format (wrapper contracts, for example), will think we transfered 2¹²⁸!

With this trick, we could create as many wrapper tokens as we wanted to and later withdraw everything from wrapper contracts.

This would drain every wrapped token on the network.

But that’s not all. With DEXes accepting native transfer of tokens to swap to any other token, we could also drain all DEXes on such a network.

To illustrate the above, here is a sample contract from Julius Brainto exploit the bug.

And to illustrate further, here is a step-by-step guide for understanding how the exploit works practically:

1. Deploy the above exploit contract onto the Moonbeam network with the address of the Wrapped MOVR contract.

2. Call depositWMOVR() function with msg.value=0 . The val will be evaluated into 2¹²⁸ + 0. This will mean that during the deposit into WMOVR, we won’t be transferring any MOVR as it will be truncated to 0.

3. Call withdrawMOVR(). The WMOVR contract will think we deposited 2¹²⁸ in the previous step thus allowing us to get 2¹²⁸ MOVR by only paying for the transaction fees!

4. Profit.

The estimated value that could have been lost across Moonbeam, Acala, and Astar was nearly $200m. That includes direct money taken from wrapper contracts and major DEXes that accept swaps from native tokens to any ERC20-like tokens.

Moonbeam released a new Runtime 1606 which addressed the issue by removing the truncation. More information about the fix can be found here in their security announcement.

As Moonbeam is also one of the maintainers of the library, they released a bug fix. The code can be found here.

We would like to thank pwning.eth for responsibly disclosing such an important bug. Major congratulations also to the Moonbeam team, Acala, Astar, and Parity who responded quickly to the report and moved towards a resolution together.

If you’re a web2 or web3 developer who is finally thinking about a bug-hunting career in web3, we got you. Check out our Web3 Security Library, and start taking home some of the $140m in rewards available on Immunefi — the leading bug bounty platform for web3.

And if you’re feeling good about your skillset and want to see if you can find some bugs, check out the bug bounty programs from Moonbeam, Acala, and Astar.