Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TRSRY susceptible to loan / withdraw confusion #75

Open
code423n4 opened this issue Aug 30, 2022 · 3 comments
Open

TRSRY susceptible to loan / withdraw confusion #75

code423n4 opened this issue Aug 30, 2022 · 3 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) old-submission-method sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-08-olympus/blob/main/src/modules/TRSRY.sol#L64-L102

Vulnerability details

Impact

Treasury allocates approvals in the withdrawApproval mapping which is set via setApprovalFor(). In both withdrawReserves() and in getLoan(), _checkApproval() is used to verify user has enough approval and subtracts the withdraw / loan amount. Therefore, there is no differentiation in validation between loan approval and withdraw approval. Policies which will use getLoan() (currently none) can simply withdraw the tokens without bookkeeping it as a loan.

Proof of Concept

  1. Policy P has getLoan permission
  2. setApprovalFor(policy, token, amount) was called to grant P permission to loan amount
  3. P calls withdrawReserves(address, token, amount) and directly withdraws the funds without registering as loan

Recommended Mitigation Steps

A separate mapping called loanApproval should be implemented, and setLoanApprovalFor() will set it, getLoan() will reduce loanApproval balance.
@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working old-submission-method labels Aug 30, 2022
code423n4 added a commit that referenced this issue Aug 30, 2022
@code423n4
Trust issue #75
359b5ca
@ind-igo ind-igo added sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) and removed sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons labels Sep 7, 2022
@ind-igo
Copy link
Collaborator

ind-igo commented Sep 7, 2022

Confirmed. Good suggestion. Would put as low risk though.

@0xean
Copy link
Collaborator

0xean commented Sep 18, 2022

Currently thinking M is appropriate for this issue, but will circle back on it.

@0xean 0xean mentioned this issue Sep 19, 2022
Closed
@0xean
Copy link
Collaborator

0xean commented Sep 19, 2022

See #293 for a possible vector in which this could lead to loss of funds. Going to leave as M

This was referenced Sep 19, 2022
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) old-submission-method sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ind-igo @0xean @code423n4