Canto Application Specific Dollars and Bonding Curves for 1155s - vangrim's results

Lines of code

https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/1155tech-contracts/src/Market.sol#L150 https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/1155tech-contracts/src/Market.sol#L174

Vulnerability details

Impact

The Market.sol contract, which utilizes a linear bonding curve for pricing shares, is vulnerable to sandwich attacks. The susceptibility arises from the dynamic pricing model (linear bonding curve), where share prices increase with each purchase and decrease with each sale in real-time.

Proof of Concept (Linear Bonding Curve)

1. Victim's Transaction Initiation:
   • Victim (User A) initiates a transaction to buy a certain number of shares (say amountA) by calling the buy() function. The expected price for these shares is calculated using the getPriceAndFee function, starting from the current tokenCount (say N).
2. Attacker's Frontrunning Transaction:
   • Attacker (User B) observes A's pending transaction in the mempool. B submits their own buy transaction for amountB shares with a higher gas fee to ensure it's processed first.
   • B's transaction is executed first, and the getPriceAndFee function calculates the price starting from tokenCount N. The loop in getPriceAndFee iterates from N to N + amountB, incrementally increasing the price for each additional share.
3. Impact on Victim's Transaction:
   • After B's transaction, the tokenCount is incremented by amountB. Now, when A's transaction is processed, the starting point for the getPriceAndFee calculation has shifted to N + amountB.
   • The price for A's shares is now calculated starting from a higher tokenCount, resulting in a higher total price than anticipated. The loop in getPriceAndFee iterates from N + amountB to N + amountB + amountA, further increasing the price for each of A's shares.
4. Attacker's Backrunning Transaction:
   • After A's transaction is processed, B executes a sell() transaction to sell their amountB shares.
   • Since the tokenCount is now higher due to A's purchase, the price at which B sells their shares could be inflated, allowing B to realize a profit.
5. Profit Realization:
   • The attacker, having bought shares at a lower price (prior to A's purchase) and selling them at an inflated price (after A's purchase), realizes a profit. This profit comes at the expense of the original buyer, User A, who ends up paying more per share due to the increased tokenCount.

Tools Used

• Manual Review.

Recommended Mitigation Steps

There are many ways to deal with frontrunning schemes, but here are two recommendations:

1. Implement a Time Delay: Introduce a time delay between transactions for each user address. This delay would prevent users from executing buy and sell transactions in rapid succession, making sandwich attacks less feasible.

The above does not prevent a scheme where the attacker uses multiple addresses, whereas the other recommendation to implement is:

• Use a Commit-Reveal Scheme: Implement a commit-reveal mechanism for transactions. Users first commit to a transaction, and after a certain period, they reveal the transaction details. This approach can prevent attackers from front-running or back-running, as they won't have immediate visibility of transaction intentions.

Assessed type

MEV