Open code423n4 opened 2 years ago
Valid
Sending funds to an unusable address on a chain that we didn't intend to be on doesn't seem in scope, but good thinking. In any case, the exchange will have the key for the address on the other chain since private keys are chain agnostic.
Lines of code
https://github.com/code-423n4/2022-05-factorydao/blob/db415804c06143d8af6880bc4cda7222e5463c0e/contracts/MerkleDropFactory.sol#L94
Vulnerability details
https://github.com/code-423n4/2022-05-factorydao/blob/db415804c06143d8af6880bc4cda7222e5463c0e/README.md?plain=1#L28
Since these trees are long-lived, they need to be able to handle forks correctly. If someone generates an exchange address for their drops, that address may only be valid for that chain (e.g. exchange supports BTC but not BSV), and any funds sent to the unsupported chain are lost.
Impact
If there's a fork, since anyone can call
withdraw()
, an attacker can monitor the blockchain for calls towithdraw()
, and then make the same call with the same arguments on the other chain, which will send funds to the unsupported address.Proof of Concept
There are no EIP-712 protections in the encoding:
https://github.com/code-423n4/2022-05-factorydao/blob/db415804c06143d8af6880bc4cda7222e5463c0e/contracts/MerkleDropFactory.sol#L94
https://github.com/code-423n4/2022-05-factorydao/blob/db415804c06143d8af6880bc4cda7222e5463c0e/contracts/MerkleVesting.sol#L109
and anyone can trigger a withdrawal:
https://github.com/code-423n4/2022-05-factorydao/blob/db415804c06143d8af6880bc4cda7222e5463c0e/contracts/MerkleDropFactory.sol#L82-L83
Tools Used
Code inspection
Recommended Mitigation Steps
Add EIP-712 protections and add a mechanism to allow tokens to be transferred to a different address using EIP-2612
permit()