Open code423n4 opened 1 year ago
Picodes marked the issue as primary issue
asselstine marked the issue as sponsor confirmed
Picodes marked the issue as selected for report
Picodes marked the issue as satisfactory
Since most users will use the depositWithPermit
function, I've removed the mintWithPermit
one in this PR: https://github.com/GenerationSoftware/pt-v5-vault/pull/15
Lines of code
https://github.com/GenerationSoftware/pt-v5-vault/tree/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L466-L469 https://github.com/GenerationSoftware/pt-v5-vault/tree/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L971-L974 https://github.com/GenerationSoftware/pt-v5-vault/tree/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol#L882-L887
Vulnerability details
Impact
Vault.mintWithPermit()
uses a signature to approve the underlying asset. But the asset amount can be changed easily, so this method can be reverted and might be DoSed.Proof of Concept
Vault.mintWithPermit()
gets the share amount as an input and calculates the asset amount from the share. And then approves the asset amount withpermit
method.The signature is generated using the exact value of the expected asset amount calculated from the share amount, and the resulting asset amount depends on the exchange rate of current vault.
So the resulting asset amount can be different from the value of transaction start time. And even an adversary can front-run and manipulate the exchange rate. If the resulting asset amount is different from the original one, the signature will not work as expected and
mintWithPermit()
will revert in most cases.Tools Used
Manual Review
Recommended Mitigation Steps
We can input upper bound of the asset amount instead of the exact value of the asset amount.
Assessed type
DoS