Handle

cmichel

Vulnerability details

Vulnerability Details

When a user deposits to the treasury they first approve the contract and then call its deposit action which performs an ERC20.transferFrom.
It’s possible for an attacker to frontrun the final deposit transaction after the user approval and turn the deposit into a sponsor this way, which is basically a free donation to a market outcome (card).
The attacker can create their own market where they are the only participant betting on a card that is guaranteed to win.

Attack:

1. Attacker creates custom market M with a guaranteed winning card. (They can time the market close in a way such that no other user can rent the card longer then them.)
2. user A sends a transaction which approve the treasury for a deposit amount.
3. user A sends a Treasury.deposit(amount) action instead.
4. An attacker observes the deposit from 2 and frontruns it with a sponsor action from their custom market by sending a M.sponsor(A, amount) transaction.
5. This increases the payout of the card in the attacker market but takes the funds from the user in the treasury.sponsor(_sponsorAddress=A, _amount) treasury call: erc20.transferFrom(_sponsor=A, address(this), _amount);
6. The attacker wins, and can withdraw their profit at some point, essentially stealing the user’s deposit

Impact

User deposits can be stolen.

Recommended Mitigation Steps

The sponsor function should not allow specifying a custom sponsorAddress.
The market should pull in the amounts from msg.sender using ERC20.transferFrom(msg.sender, amount) and then forward this amount to the treasury using a simple ERC20.transfer(treasury, amount) followed by the treasury.sponsor call that does the remaining book-keeping.

The text was updated successfully, but these errors were encountered:

All reactions