Dria

Swan
NFTHardhat
21,000 USDC
View results
Submission Details
Severity: high
Invalid

Base chain's low gas costs make reentrancy attacks economically viable

Summary

The purchase function in Swan.sol contains critical ordering vulnerabilities in asset transfers and state management that could lead to asset theft and payment manipulation.

  • Asset theft through reentrancy

  • Payment evasion

  • Multiple purchases of same asset

  • Protocol fee bypass

Vulnerability Details

The two sequential transfers can temporarily cause the asset count for Swan (address(this)) to increase by more than 1, violating the invariant that assets should only change by +/-1.

Swan.sol#purchase: https://github.com/Cyfrin/2024-10-swan-dria/blob/c3f6f027ed51dd31f60b224506de2bc847243eb7/contracts/swan/Swan.sol#L276-L302

function purchase(address _asset) external {
// @audit-info Premature state change before asset verification
listing.status = AssetStatus.Sold;
// @audit-info Vulnerable two-step transfer pattern
// Creates exploitable intermediate state
SwanAsset(_asset).transferFrom(listing.seller, address(this), 1);
SwanAsset(_asset).transferFrom(address(this), listing.buyer, 1);
// @audit-info Late payment verification
// Asset ownership changes before payment confirmation
token.transferFrom(listing.buyer, address(this), listing.price);
token.transfer(listing.seller, listing.price);
}
  1. State changes occur before asset transfers

  2. Two-step asset transfer creates unnecessary complexity

  3. Payment occurs after asset ownership changes

This ordering violates the Checks-Effects-Interactions pattern and could allow:

  • Reentrancy attacks during the two-step asset transfer

  • Failed payments after asset ownership has changed

  • Asset theft if payment fails but transfer succeeds

The vulnerability is particularly severe because it handles both high-value NFT assets and payment tokens in the same transaction without proper safeguards.

A malicious actor could potentially manipulate the transaction ordering to obtain assets without proper payment or execute multiple purchases of the same asset.

This has high ikelihood of manifesting because

  • Base chain's low gas costs make reentrancy attacks economically viable

  • Complex interaction between ERC721 and ERC20 transfers

  • Multiple external calls in single transaction

This directly impacts

  • Asset sellers who may lose NFTs

  • Buyers who could have assets stolen

  • Protocol fee collection

Impact

  • The purchase function violates CEI (Checks-Effects-Interactions) pattern

  • State changes occur before external calls

Tools Used

Vs

Recommendations

Implement nonReentrant modifier and ensure atomic operations by using a pull payment pattern for asset transfers. Add payment verification before any state changes or transfers occur.

Updates

Lead Judging Commences

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Lack of quality

Support

FAQs

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