obront - L1 contract can evade aliasing, spoofing unowned L2 address #39
Labels
Sponsor Confirmed
The sponsor acknowledged this issue is valid
Will Fix
The sponsor confirmed this issue will be fixed
obront
High
L1 contract can evade aliasing, spoofing unowned L2 address
Summary
A key property of the Optimism bridge is that all contract addresses are aliased. This is to avoid a contract on L1 to be able to send messages as the same address on L2, because often these contracts will have different owners. However, using the
onApprove()
function, this aliasing can be evaded, giving L1 contracts this power.Root Cause
When
depositTransaction()
is called on the Optimism Portal, we use the following check to determine whether to alias thefrom
address:As we can see, this check does not alias the address is
_isOnApproveTrigger = true
.This flag is set whenever the deposit is triggered via a call to
onApprove()
. However, it is entirely possible for a contract to use this flow, and therefore avoid being aliased.Internal Preconditions
None
External Preconditions
None
Attack Path
transfer()
on an ERC20 to steal their tokens.approveAndCall()
on the Native Token on L1, including the message it wants to send on L2.onApprove()
function, which sets the_isOnApproveTrigger
flag to true, and doesn't alias the address.from
the unaliased L1 address, and arbitrary messages (including token transfers) can be performed on L2.Impact
L1 contracts can send arbitrary messages from their own address on L2, allowing them to steal funds from the owners of the L2 contracts.
PoC
The following standalone test can be used to demonstrate this vulnerability:
Mitigation
The
_sender != tx.origin
check is correct, even in the case that the call came viaonApprove()
, so the additional logic can be removed.The text was updated successfully, but these errors were encountered: