Taiko - lanrebayode77's results

A based rollup -- inspired, secured, and sequenced by Ethereum.

General Information

Platform: Code4rena

Start Date: 04/03/2024

Pot Size: $140,000 USDC

Total HM: 19

Participants: 69

Period: 21 days

Judge: 0xean

Total Solo HM: 4

Id: 343

League: ETH

Taiko

Findings Distribution

Researcher Performance

Rank: 46/69

Findings: 1

Award: $177.52

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Labels

bug
2 (Med Risk)
satisfactory
:robot:_26_group
duplicate-298

Awards

177.522 USDC - $177.52

External Links

Lines of code

https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/bridge/Bridge.sol#L97-L98 https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/bridge/Bridge.sol#L271

Vulnerability details

Impact

It will be possible for users to make calls to contract addresses that have been banned, which ideally should be impossible.

Proof of Concept

Calls to banned addresses should be impossible.

  /// @notice Ban or unban an address. A banned addresses will not be invoked upon
    /// with message calls.
    /// @param _addr The address to ban or unban.
    /// @param _ban True if ban, false if unban.
    function banAddress(

In processMessage(), there is a check to prevent making calls to a banned address that sends ether to the refund address set by the user.

  // Process message differently based on the target address
            if (
                _message.to == address(0) ||
                _message.to == address(this) ||
                _message.to == signalService ||
                addressBanned[_message.to] //@audit what if refund address is banned too???
            ) {
                // Handle special addresses that don't require actual invocation but
                // mark message as DONE
            @>  refundAmount = _message.value; //value will be refunded 
                _updateMessageStatus(msgHash, Status.DONE); //will be marked done
            } else {

If the user sets _message.refundTo = bannedAddress, eth will be sent there and fallBack can run desired logic based on user parameters.

// Determine the refund recipient
            address refundTo = _message.refundTo == address(0)
                ? _message.destOwner
                : _message.refundTo; //@audit use a banned address and intended call will run when eth is sent

Refund is done here;

// Refund the processing fee
            if (msg.sender == refundTo) {
                refundTo.sendEther(_message.fee + refundAmount);
            } else {
                // If sender is another address, reward it and refund the rest
                msg.sender.sendEther(_message.fee);
                refundTo.sendEther(refundAmount);     
            }

Bypass flow;

  1. Admin bans an address for a certain reason to prevent any call from being made to the address.
  2. Banned contract address is upgraded to include certain function calls in fallback and requires to be called by just receiving ether.
  3. User set _message.refundTo as bannedAddress, no check to prevent this in sendMessage()
  4. when a message is processed, a refund to the address triggers the call to the banned address

Tools Used

Manual review

Add a check to prevent sending ether to a banned address.

Assessed type

Invalid Validation

#0 - c4-pre-sort

2024-03-28T00:47:28Z

minhquanym marked the issue as duplicate of #349

#1 - c4-judge

2024-04-09T18:00:43Z

0xean changed the severity to QA (Quality Assurance)

#2 - c4-judge

2024-04-10T11:45:29Z

0xean marked the issue as grade-c

#3 - lanrebayode

2024-04-10T17:03:41Z

Hi @0xean, Thanks for judging.

Please kindly take a second look at this. This report is not a Duplicate of the main issue #349. The primary issue is about transferring ETH to banned address, which according to sponsor comment is not an issue.

Banning an address is not to prevent sending Ether to it, but to prevent calling its function. I think my action is to dispute.

According to the sponsor comment above, the aim of having banned address is to prevent function calls to such address and that is exactly what this report is all about.

Actually, it is possible call functions in banned address if the contract is updated to route calls through fallback and by simply setting refundTo as a banned address, any function in the contract fallback will succed.

#4 - 0xean

2024-04-11T09:36:17Z

@dantaik @adaki2004 - care to comment on the above response from the Warden?

#5 - c4-judge

2024-04-12T14:10:11Z

0xean removed the grade

#6 - c4-judge

2024-04-12T14:10:25Z

This previously downgraded issue has been upgraded by 0xean

#7 - c4-judge

2024-04-12T14:10:32Z

0xean marked the issue as not a duplicate

#8 - c4-judge

2024-04-12T14:10:40Z

0xean marked the issue as duplicate of #298

#9 - c4-judge

2024-04-12T14:15:12Z

0xean marked the issue as satisfactory

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter