DittoETH

Summary

timeTillMatch in the function increaseSharesOnMatch on LibOrders.sol is incorrectly calcuted. The function increaseSharesOnMatch will always revert due underflow in the timeTillMatch calculation.

Vulnerability Details

The function increaseSharesOnMatch will always revert due underflow in the timeTillMatch calculation.

The getOffsetTime() function calculates the offset time as
block.timestamp - Constants.STARTING_TIME the block.timestamp is in present and STARTING_TIME is in past. So there is no issue with this there. But when we look into increaseSharesOnMatch function
this calculates the timeTillMatch as getOffsetTime() - order.creationTime
Here orderCreation will be something in past and when we use calculate this using getOffsetTime, it will revert due to Underflow.

The attack POC and Attack Scenario is provided:

POC(Chisel):

Attack Scenario:

1. block.timestamp is higher than STARTING_TIME which gives a value around 35177121 range as of now. using getOffsetTime() function,

2. The orderCreationTime is something in the past which is greater than 35177121 because this value represents something 53 years ago.

3. Ultimately uint32 timeTillMatch = getOffsetTime() - order.creationTime; will revert due to underflow.

Impact

All the instances where increaseSharesOnMatch is being used are going to fail in the protocol resulting a damage in protocol logic flow.

Tools Used

Manual Review.

Recommendations

Check if the getOffsetTime is greater than the order.creationTime and if that is true, reverts the function.