Closed code423n4 closed 2 years ago
This is not a duplicate, since the underlying issue is different (this one points out an error in the accounting of userProposalFractions
, while #441 points to an accounting error in the tally of a proposal as a whole.
Lines of code
https://github.com/code-423n4/2022-07-fractional/blob/e2c5a962a94106f9495eb96769d7f60f7d5b14c9/src/modules/Migration.sol#L49
Vulnerability details
Impact
The variable userProposalFractions in the contract Migration accounts the fractions provided for a proposal id globally, instead of accounting it for a combination of id + specific vault. That means if Bob provides his A-tokens for proposal #1 of A-Vault and Eve provides her E-Tokens (which she can mint out of thin air) for proposal #1 of her E-Vault, Eve is able to withdraw A-Tokens that originally belonged to Bob. Furthermore Bob will not be able to withdraw his Ether provided for the proposal as the attempt will revert due to lack of A-Tokens in the migration contract.
Proof of Concept
The following code follows the initial setup of Migration.t.sol and expands on it to show how the exploit works:
Tools Used
Recommended Mitigation Steps
Similarly to the mapping migrationInfo in Migration.sol the mapping for userProposalFractions needs vault addresses as a first key:
The same needs to apply to userProposalEth, else the accounting will be wrong and cause errors when there are multiple simultaneous migration proposals.