Denial of Service when vectorx address is changed

Summary

Avail Bridge can cause DOS by not processing proofs from any previous vectorx contract attached to it.

Vulnerability Detail

Since avail bridge can only process proofs which are committed on vectorx, but vectorx can be changed and throughout its lifetime it can hold multiple values. However, it can only allow proofs to be process from any one of them causing proofs containing token / data to be remain locked.

Impact

Once vectorx is changed using updateVectorx then receiveMessage, receiveAVAIL and receiveETH will not allow to use proofs to verify their inputs and do the necessary unlocks on any of message in previous root commitments which are not unlocked resulting in DOS by not being able to unlock tokens / data on ethereum and also it being simultaneously marked as sent from avail since commitment is posted.

If updateVectorx is called again to rollback to old vectorx address, then proofs from new vectorx can't be processed.

Code Snippet

Tool used

Manual Review

Recommendation

Make vectorx immutable and if there is need to change vectorx, a new bridge contract should be deployed with new vectorx. Alternatively, avail bridge should have logic to handle more than one vectorx if it can be changed.

sherlock-admin commented 8 months ago

1 comment(s) were left on this issue during the judging contest.

takarez commented:

invalid because {invalid: admin function}

QEDK commented 8 months ago

Responding here because the Watson requested a review. This is a known trusted vector, we would need some sort of migration mechanism if such a change were to occur.

sherlock-audit / 2023-12-avail-judging

ten-on-ten - Denial of Service when vectorx address is changed #118