agent3bood - Attacker will mint more tokens on L2 than deposited on L1

[sherlock-admin2]

agent3bood

High

Attacker will mint more tokens on L2 than deposited on L1

Summary

The missing validation between deposited and minted token amounts in OptimismPortal2._depositTransaction will cause a significant loss of funds for the protocol as an attacker will mint more tokens on L2 than they actually deposit on L1 through either the onApprove callback or direct depositTransaction call on the OptimismPortal2 contract.

Root Cause

In OptimismPortal2.sol, the _depositTransaction function, which is called by both onApprove and depositTransaction, does not validate that the _value parameter (amount to be minted on L2) is equal to the _mint parameter (amount transferred on L1). This allows for a mismatch between deposited and minted token amounts.

https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/OptimismPortal2.sol#L513

This can happen when using the OptimismPortal2 without going through the bridge or messenger, looking at the messenger code we can see that the two parameters are assumed equal.

https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol#L79

Internal pre-conditions

No specific pre-conditions are required.

External pre-conditions

No specific pre-conditions are required.

Attack Path

1. The attacker chooses either to use approveAndCall on the native token contract or to directly call depositTransaction on OptimismPortal2.
2. If using approveAndCall:

• Attacker approves a small amount (or zero tokens) to OptimismPortal2 by calling nativeTOken.approveAndCall(..., data).
• In the data parameter, attacker specifies a much larger value.
• The OptimismPortal2.onApprove will extract the value from the user specified data and call _depositTransaction
• https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/OptimismPortal2.sol#L469

3. If using depositTransaction:

• Attacker directly calls the function with a small _mint value and a larger _value.
• The _depositTransaction function is called.
• https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/OptimismPortal2.sol#L498

4. The _depositTransaction will get called which will
   • Transfer _mint amount from the user
   • https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/OptimismPortal2.sol#L530
   • Send _value amount to the L2 receiver
   • https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/packages/tokamak/contracts-bedrock/src/L1/OptimismPortal2.sol#L554
   • Emits TransactionDeposited event
   • The L2 system processes this deposit event and mints tokens based on the larger _value in the opaque data.
   • https://github.com/sherlock-audit/2024-08-tokamak-network/blob/main/tokamak-thanos/op-node/rollup/derive/deposit_log.go#L114

Impact

The protocol suffers a significant loss of funds. Attackers can mint arbitrary amounts of tokens on L2 while depositing only a small amount (or potentially zero) on L1. The attacker gains the difference between the deposited amount and the minted amount on L2.

PoC

No response

Mitigation

Modify the _depositTransaction function in OptimismPortal2 to ensure that the _value parameter (amount to be minted on L2) equals the _mint parameter.