search

code-423n4 / 2021-08-gravitybridge-findings

1 stars 0 forks source link

The reward mechanism is front-runnable #52

Closed code423n4 closed 2 years ago

code423n4 commented 2 years ago

Handle

hrkrshnn

Vulnerability details

The reward mechanism is front-runnable

Once the function submitBatch lands in the mempool, anyone can copy the calldata arguments and front run the call, taking away the fees. This means that the user's tx will revert, paying for the gas. The issue here is that if the protocol relies on 'regular' users to submit transactions on the chain, then the incentive mechanism is broken.

The above problem means that only private ethereum transactions (i.e., using flashbots, taichi or perhaps eden) will make the reward mechanism work. Consider changing the submitBatch function where msg.sender can also be signed by the validators, preventing such front running issues.

Another approach is to ignore this issue and encourage the bots by posting it under mev-job-board.

jkilpatr commented 2 years ago

This is the intent of issuing rewards on the Ethereum side of the bridge. If we wanted to hide them from MEV we would have issued them on the Cosmos side. So this is not a bug, but in fact a feature in our opinion. There is no vulnerability to the secure operation of our system.

duplicate of #33, #10

mev-job-board is interesting, thanks for the link.

albertchon commented 2 years ago

Consider changing the submitBatch function where msg.sender can also be signed by the validators, preventing such front running issues.

that'd actually be a worse design that would hurt the security of the system