API crash preventing correct processing of deposits
Description
Brief/Intro
An attacker can call Emily.create_deposit and pass in a Confiered deposit to overwrite the status of the deposit to Pending, thereby causing the Signer to process a deposit repeatedly.
Note that even if the integrity issue with Emily.create_deposit is fixed, this issue will still exist, because the issue is not related to integrity, it is about re-creating an already Confiermed deposit.
Vulnerability Details
The Emily.create_deposit code is as follows.
It will insert the deposit into the table in the Pending state. It will not check whether the deposit already exists. Therefore, if the deposit has been Confiermed, it will be overwritten as Pending.
Impact Details
The signer will pull all pending deposits from Emily for processing each time. If an attacker overwrites the status of all historical deposits to pending, the signer will reprocess all deposits at once. This may make it difficult for the signer to handle so many deposits. In addition, these deposits will be submitted to the Stacks chain (which will fail to execute), and the signer may lose a lot of gas fees. The signer may also be unable to submit a new deposit due to insufficient gas fees.
References
None
Proof of Concept
Proof of Concept
Add this test case to emily/handler/tests/integration/deposit.rs