Open code423n4 opened 2 years ago
Understood. Will change the logic to increase/decrease allowances.
I commented in #77 before getting to this ticket. I think this vulnerability should be a high severity as it opens up the possibility of a direct loss of funds in the amount of up to the previous approval amount. Upgrading to H.
@ind-igo - Not sure if you deleted your comment, but that context is useful. Happy to take another look here.
I did, I just thought it was unnecessary to evaluate the issue. I was just saying that the context of the code is that it is not intended to be used to approve an EOA/multisig, but instead used to approve governance-voted contracts to access treasury funds, in order to deposit into yield contracts or whatever. But I don't think its very relevant to this, as the code is still faulty and exploitable in an extreme case. I already have made this remediation as well, so all good.
Lines of code
https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/modules/TRSRY.sol#L64-L72 https://github.com/code-423n4/2022-08-olympus/blob/b5e139d732eb4c07102f149fb9426d356af617aa/src/policies/TreasuryCustodian.sol#L42-L48
Vulnerability details
Impact
An attacker may be able to withdraw more than intended
Proof of Concept
Let's say the alice had approval of 100. Now the treasury custodian reduced the approval to 50. Alice could frontrun the
setApprovalFor
of 50, and withdraw 100 as it was before. Then withdraw 50 with the newly set approval. So the alice could withdraw 150.The
TreasuryCustodian
simply calls thesetApprovalFor
to grant Approval.Tools Used
none
Recommended Mitigation Steps
Instead of setting the given amount, one can reduce from the current approval. By doing so, it checks whether the previous approval is spend.