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

Lines of code

https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/bonding_curve/LinearBondingCurve.sol#L14-L25 https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/Market.sol#L150-L169 https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/Market.sol#L174-L189

Vulnerability details

Impact

Because of the linear price increase(LinearBondingCurve) it can be really easy to manipulate the price for next buyer of the shares in the Market.

While sandwich attack is not a problem since the contracts will be deployed to Canto(l2 based on Polygon) there still a possibility of price manipulation attack which will affect user expenses and can be profitable for the malefactor.

**It also worth to mention that during the audit representative of the Canto team - Roman, mentioned that it is possible that this contract will be deployed on other chains. So potential sandwich attack vulnerability is also possible and should be addressed. https://discord.com/channels/810916927919620096/1172195122230853723/1173936821479161866 Roman(c) >> Application specific dollars will only be deployed on Canto. 1155tech may be deployed on other chains in the future (with a different payment token), but the current focus / plan is also the deployment on Canto

Proof of Concept

The simplest flow is an example where the shares creator is malefactor contract.

1. Creator creating new share via the Market. https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/Market.sol#L114-L127 Per documentation Market.createNewShare is used to create a new share. Share creation can be completely permissionless or it can be restricted to whitelisted addresses only. No fee is charged for the creation of new shares.

        require(whitelistedBondingCurves[_bondingCurve], "Bonding curve not whitelisted");
        require(shareIDs[_shareName] == 0, "Share already exists");
        id = ++shareCount;
        shareIDs[_shareName] = id;
        shareData[id].bondingCurve = _bondingCurve;
        shareData[id].creator = msg.sender;
        shareData[id].metadataURI = _metadataURI;
        emit ShareCreated(id, _shareName, _bondingCurve, msg.sender);

2. During same transaction malicious contract can buy tokens from newly created share by changing msg.sender. For example he takes 100 tokens. The price paid will be: (1..100)*priceIncrease https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/Market.sol#L150-L169

 require(shareData[_id].creator != msg.sender, "Creator cannot buy"); //@audit this check is nor enough for protection from current attack

3. Prices for this share will be increased. By the algorithm token for new user will cost: (100+1)*priceIncrease https://github.com/code-423n4/2023-11-canto/blob/main/1155tech-contracts/src/bonding_curve/LinearBondingCurve.sol#L14-L25

        for (uint256 i = shareCount; i < shareCount + amount; i++) {
            uint256 tokenPrice = priceIncrease * i;
            price += tokenPrice;
            fee += (getFee(i) * tokenPrice) / 1e18;
        }

4. After other users of the Market will buy enough shares the attacker will just sell everything and get a profit. Users buy next 100 tokens with price (100+1..100)*priceIncrease. Attacker sell 100 tokens with price (200-1..100)*priceIncrease. Profit will be the difference between price of last 100 tokens and first 100 tokens.

5. Because this early-start manipulation is possible for multiple shares it can be replicated many times.

Tools Used

Manual audit

Recommended Mitigation Steps

1. Make some protection/pause logic for malicious shares to protect users from buy/sell.
2. Make pricing logic a bit smarter with snapshot pricing.

Assessed type

Other