wellbyt3 - bridgeERC20 withdraws get nativeToken stuck on L2

[sherlock-admin4]

wellbyt3

Medium

bridgeERC20 withdraws get nativeToken stuck on L2

Summary

Since native token is an ERC20, a user may try to withdraw native token, but using the bridgeERC20 function. If this happens, tokens get stuck on the L2 and can't be bridged to the L1.

Root Cause

There's no check that stops a user from calling bridgeERC20 on the L2 and passing in the ERC20 nativeTokens. This is plausible because these tokens are ERC20s.

Internal pre-conditions

1. A user calls bridgeERC20 on the L2 passing in the native token addresses as the token addresses.

External pre-conditions

N/A

Attack Path

There's no check that stops a user from calling bridgeERC20 on the L2 and passing in the ERC20 nativeToken.

In _initiateBridgeERC20, the native token will return false here: https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/universal/StandardBridge.sol#L428

So instead of it being burned, it'll be transferred and state for deposits will be updated.

Then, on the L1, when relayMessage calls finalizeBridgeERC20, the following line will return false:

https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/universal/StandardBridge.sol#L348

Then the transaction will revert due to underflow (nativeToken is blocked on deposits if you try to call bridgeERC20, so deposits[nativetoken][nativetoken] will always be 0 on the L1): https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/universal/StandardBridge.sol#L356

Impact

Loss of funds for withdrawing users of native token.

PoC

No response

Mitigation

Prevent users from withdrawing native token using bridgeERC20 or bridgeERC20To.