Tadle
Tadle
DeFiFoundry
27,750 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Maker Can Retrieve Tokens Multiple Times from Closed Offers

hunter_w3b

Summary

An attacker can exploit this vulnerability by creating an offer, closing it, and then repeatedly calling the abortAskOffer() function. This allows the attacker to retrieve their tokens multiple times, resulting in a loss of funds for the protocol.

Vulnerability Details

  • Offer Creation (createOffer): A maker creates an offer, locking tokens as collateral.

  • Offer Closure (closeOffer): Then maker calls closeOffer(), retrieves their locked tokens, and effectively cancels the offer.

  • abort ask offer (abortAskOffer): After closing the offer, the maker calls abortAskOffer() again, which incorrectly allows them to retrieve the locked tokens a second time.

The abortAskOffer() function fails to verify the offer's current status before executing the transaction. As a result, the maker can exploit this flaw to reclaim their tokens multiple times, effectively draining the protocol's funds without returning any points.

Attack Scenario

  • Maker Creates Offer: A malicious maker calls createOffer(), locking tokens as collateral.

  • Maker Closes Offer: The maker calls closeOffer() to retrieve the locked tokens, canceling the offer.

  • Double Refund Exploit: The maker then calls abortAskOffer(), exploiting the lack of proper state validation to receive an additional refund of their tokens.

function test_ask_offer_turbo_usdc() public {
vm.startPrank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
1 * 1e18,
10000,
300,
OfferType.Ask,
OfferSettleType.Turbo
)
);
address offerAddr = GenerateAddress.generateOfferAddress(0);
address stockAddr = GenerateAddress.generateStockAddress(0);
preMarktes.closeOffer(stockAddr, offerAddr);
console2.log(tokenManager.getBalance(address(mockUSDCToken), TokenBalanceType.MakerRefund));
preMarktes.abortAskOffer(stockAddr, offerAddr);
console2.log(tokenManager.getBalance(address(mockUSDCToken), TokenBalanceType.MakerRefund));
}
Ran 1 test for test/PreMarkets.t.sol:PreMarketsTest
[PASS] test_ask_offer_turbo_usdc() (gas: 612429)
Logs:
1000000000000000000
2000000000000000000
​
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 6.21ms (661.43µs CPU time)

Impact

The impact is critical. This vulnerability allows the maker to repeatedly withdraw funds, potentially leading to significant losses for the protocol.

Tools Used

Manual Review, Foundry

Recommendations

Implement a check within the abortAskOffer() function to ensure that the offer is still valid and has not been closed before allowing the transaction to proceed.

Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

[invalid] finding-PreMarkets-abortAskOffer-Canceled exploit

Note, #148, #826, #1784 all stems from the fact that order statuses are not appropriately updated when a taker order is created against a maker offer. If the status is switched to `Ongoing/Filled` respectively, the virgin checks will fail appropriately and subsequently all this issues will be fixed. They could possibly be duplicates, so leaving open for appeal. This actually is closely related to issue #148. If a taker has created an Bid/Ask offer agains a original maker offer and the Status is adjusted to Ongoing/Filled accordingly, then the abortion/cancellations cannot occur so this issue cannot be exploited.

Appeal created

0xbrivan2 Auditor
about 1 year ago
0xnevi Lead Judge
about 1 year ago
0xnevi Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

[invalid] finding-PreMarkets-abortAskOffer-Canceled exploit

Note, #148, #826, #1784 all stems from the fact that order statuses are not appropriately updated when a taker order is created against a maker offer. If the status is switched to `Ongoing/Filled` respectively, the virgin checks will fail appropriately and subsequently all this issues will be fixed. They could possibly be duplicates, so leaving open for appeal. This actually is closely related to issue #148. If a taker has created an Bid/Ask offer agains a original maker offer and the Status is adjusted to Ongoing/Filled accordingly, then the abortion/cancellations cannot occur so this issue cannot be exploited.

Support

FAQs

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