Summary

In the case where buyer does not call confirmReceipt() after receiving goods/services, the funds will remain stuck in the contract if arbiter is not set. Note that arbiter is not mandatory in escrow so this could be a critical.

Vulnerability Details

The vulnerability stems from the fact that arbiter is not mandatory for deploying a escrow from factory. The funds are sent prior to deployment and could remain stuck in the contract if a 'malicious' buyer refuses to confirm the receipt for services received.

This is a good chance that this will happen in at least few cases and escrow gives no option to withdraw funds to either accounts after a while (say 1 year).

It could be beneficial for the escrow system if arbiter could be set (after consensus of both buyer and seller parties) so any unresolved disputes could be brought to conclusion.

Impact

Medium/High: Funds could remain stuck in contract, and benefits no one considering no time limit is set to unlock the funds. Specially in the case where there is no dispute, but buyer claiming to be innocent refuses to pay for the goods/services.

Tools Used

Manual

Recommendations

Make arbiter mandatory in the protocol. Or use block.timestamp to make the funds withdrawable by the seller after a while (say 1 year).

An even better solution:

It would be beneficial for the escrow system if arbiter could be set post-deployment (after consensus of both buyer and seller parties), so any unresolved amassed disputes could be brought to conclusion and funds could be transferred to its rightful owner)