No protection against conduit front-running

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-delegate/blob/a6dbac8068760ee4fc5bababb57e3fe79e5eeb2e/src/libraries/CreateOffererLib.sol#L393-L401 https://github.com/code-423n4/2023-09-delegate/blob/a6dbac8068760ee4fc5bababb57e3fe79e5eeb2e/src/libraries/CreateOffererLib.sol#L257-L263

Vulnerability details

Impact

A malicious conduit could front-run and prevent the transfer

Proof of Concept

The conduit is trusted to conduct the transferFrom in the resulting order. A malicious conduit could front-run and prevent the transfer. calculateOrderHash(): This uses the conduit address as an input to generate the order hash. Once the order hash is generated, it is used to create the delegate token in createAndValidateDelegateTokenId() So the conduit address is fixed at the time of order hash generation and delegate token creation. A malicious conduit could:

1. Predict the order hash by observing the parameters
2. Front-run the transaction and call Seaport's fulfillOrder() with those parameters first
3. Specify itself as the recipient in fulfillOrder(), preventing the intended transfer This is a vulnerability because the conduit is trusted with an important transfer without a way to enforce correct behavior.

Tools Used

Manual

Recommended Mitigation Steps

• Use a proxy conduit that can be upgraded if necessary • Build review period into create flow • Use commit-reveal scheme to hide order hash

Assessed type

Other

[0xfoobar]

We will use honest conduits, the same as OpenSea, here

[c4-sponsor]

0xfoobar (sponsor) disputed

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory: Invalid