Blur Exchange contest - 0xRobocop's results

Lines of code

https://github.com/code-423n4/2022-10-blur/blob/2fdaa6e13b544c8c11d1c022a575f16c3a72e3bf/contracts/matchingPolicies/StandardPolicyERC1155.sol#L33 https://github.com/code-423n4/2022-10-blur/blob/2fdaa6e13b544c8c11d1c022a575f16c3a72e3bf/contracts/matchingPolicies/StandardPolicyERC1155.sol#L59

Vulnerability details

Impact

Detailed description of the impact of this finding.

The impact of this vulnerability is that the buyer will get less ERC1155 tokens than he/she paid.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

The ERC1155 standard is mix of erc20 and erc721 tokens, it means that you can have more than one instance of a given token id, for example you can own 5 instances of token id # n (for any n) on an ERC1155 collection.

The blur documentation says that the order struct accepts as parameter an "amount" so the contract can manage the ERC1155 tokens.

But at LoC 33 and LoC 59 at the StandardPolicyERC1155.sol contract, this "amount" parameter of the Order struct is not been used, instead a "1" is hardcoded.

So for example if seller want to sell 5 tokens of token id # n (for any n) of some collection, he will create a sell order with amount equal to 5 and the corresponding price for the 5. If the buyer want to accept the deal and submits valid buy order for the price asked by the seller, he will receive 1 token instead of 5.

This works the same if buyer is the "maker".

This can be easily tested with unit tests.

Tools Used

Manually reviewed

Recommended Mitigation Steps

Used the amount specified in the order struct, instead of the hardcoded "1"