First Flight #4: Boss Bridge
First Flight #4
Beginner FriendlyFoundryBridge
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

Using `vault` address in arbitrary `from` in `transferFrom` Function

codelock

Summary

This issue involves the utilization of vault address as arbitrary from in the transferFrom function within the depositTokensToL2 function in the file L1BossBridge.sol.

Vulnerability Details

Upon a manual review and employing tools such as 4nalizer and Slither, it was discovered that the depositTokensToL2 function employs an arbitrary from in the transferFrom function. This allows anyone to specify the address of the vault contract, facilitating the withdraw of the funds from the vault contract in the L2. The severity of this issue lies in the fact that if an user initiates a deposit from the vault contract to the same vault address, that user can obtain tokens from the bridge on the L2 network without depositing in the L1.

Here's the relevant code snippet:

function depositTokensToL2(address from, address l2Recipient, uint256 amount) external whenNotPaused {
if (token.balanceOf(address(vault)) + amount > DEPOSIT_LIMIT) {
revert L1BossBridge__DepositLimitReached();
}
token.safeTransferFrom(from, address(vault), amount);
​
// Our off-chain service picks up this event and mints the corresponding tokens on L2
emit Deposit(from, l2Recipient, amount);
}

And here's a relevant test scenario:

function setUp() public {
vm.startPrank(deployer);
​
// Deploy token and transfer the user some initial balance
token = new L1Token();
token.transfer(address(user), 1000e18);
​
// Deploy bridge
tokenBridge = new L1BossBridge(IERC20(token));
vault = tokenBridge.vault();
​
// Add a new allowed signer to the bridge
tokenBridge.setSigner(operator.addr, true);
​
vm.stopPrank();
}
​
function testhackerCanDepositTokensFromAUser() public {
uint256 amount = 10e18;
​
// Hacker can deposit tokens from the vault
vm.startPrank(hacker);
assertEq(token.balanceOf(address(vault)), amount);
tokenBridge.depositTokensToL2(vault, userInL2, amount);
assertEq(token.balanceOf(address(tokenBridge)), 0);
assertEq(token.balanceOf(address(vault)), amount);
vm.stopPrank();
}

Impact

The impact of this issue is deemed high, as it exposes the funds to potential risks. The current implementation allows an attacker to manipulate the from parameter to use the vault address, leading to the unauthorized withdrawal of tokens from the bridge in other network.

Tools Used

  • Manual Review

  • 4nalizer

  • Slither

Recommendations

To mitigate this issue, it is strongly recommended to replace the arbitrary from with msg.sender within the depositTokensToL2 function. This adjustment will prevent potential exploits and unauthorized access to the funds, enhancing the security of the contract.

Updates

Lead Judging Commences

0xnevi Lead Judge almost 2 years ago
Submission Judgement Published
Validated
Assigned finding tags:

depositTokensToL2(): abitrary from address

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.