-
Notifications
You must be signed in to change notification settings - Fork 1
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.
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
Lack of access control and value validation in the reward flow exposes functions to public access #38
Comments
@toshiSat I believe best solution is to get rid of _amount and only use msg.value here |
0xleastwood marked the issue as primary issue |
0xleastwood marked the issue as duplicate of #33 |
0xleastwood marked the issue as satisfactory |
0xleastwood changed the severity to 2 (Med Risk) |
0xleastwood changed the severity to QA (Quality Assurance) |
@0xleastwood Liam, sorry, may I ask why this issue was downgraded? It seems it was linked somehow to #33 which got downgraded recently. The exposed functions here are part of both core contracts. |
Oops, I have no idea what happened here. This was not meant to be downgraded. Apologies. |
This previously downgraded issue has been upgraded by 0xleastwood |
Oh wait this was a dupe of an issue I downgraded. Let me confirm. |
0xleastwood marked the issue as not a duplicate |
0xleastwood removed the grade |
0xleastwood marked the issue as selected for report |
0xleastwood marked the issue as satisfactory |
0xleastwood removed the grade |
0xleastwood marked the issue as primary issue |
@0xleastwood I mentioned this issue in L-08. However, note that the contracts do not hold any ETH (except dust or if sent there by mistake) so calling these functions directly wouldn't really do anything. And if there is any ETH in the contract it is just deposited as rewards, which is the only way it should be spent; it cannot be made to send it elsewhere. |
These are not equivalent, you talk about the fact that |
And what is the impact according to #38? |
I'm not stating any direct theft of funds (in fact it is mentioned in the report), hence the med severity. It's the combination of both issues that conflicts with the protocol specs:
|
Conflicting with protocol specs is QA. |
No, it's medium
|
Agree, it is medium. |
@romeroadrian, "the function of the protocol or its availability could be impacted" is not the same a conflicting with specs; function and availability is not specs. In what way do you mean that the protocol stops working? |
I believe this solves it based on original authors recommendation: also |
elmutt (sponsor) confirmed |
Lines of code
https://github.com/code-423n4/2023-09-asymmetry/blob/main/contracts/strategies/votium/VotiumStrategyCore.sol#L203
https://github.com/code-423n4/2023-09-asymmetry/blob/main/contracts/AfEth.sol#L272
Vulnerability details
Summary
Some functions that are part of the Votium reward flow are left unprotected and can be accessed by anyone to spend resources held by the contract.
Impact
Rewards coming from the Votium protocol are claimed and compounded back in AfEth. This flow consists of two parts, both controlled and initiated by the rewarder role: first, rewards are claimed in Votium and Convex using
claimRewards()
, second, those rewards are swapped to ETH and deposited back in the protocol usingapplyRewards()
.After rewards are swapped, the VotiumStrategy will call AfEth to manage the deposited rewards, which eventually calls back the VotiumStrategy. These interactions are represented in the previous diagram as steps 5 and 6.
However, both of the functions that implement these steps are publicly accessible and don't have any validation over the amount of ETH sent. Let's first see the case of
AfEth::depositRewards()
:As we can see in the previous snippet of code, the function doesn't have any access control and doesn't check if the
_amount
parameter matches the amount of ETH being sent (msg.value
). Anyone can call this function with any amount value without actually sending any ETH value.The implementation of
depositRewards()
inVotiumStrategyCore
has the same issue:Any ETH held in these two contracts can be arbitrarily spent by any unauthorized account. The caller cannot remove value from here, unless sandwiching the trade or benefitting via a third-party call, but can use these functions to grief and unauthorizedly spend any ETH present in these contracts.
Recommendation
If these functions are indeed intended to be publicly accessible, then add a validation to ensure that the amount argument matches the callvalue sent, i.e.
require(_amount == msg.value)
.On the other hand, if these should only be part of the reward flow initiated by the rewarder role, then validate that
AfEth::depositRewards()
is called from the Votium Strategy (vEthAddress
), and validate thatVotiumStrategy::depositRewards()
is called either from AfEth (manager
) or internally throughapplyRewards()
.Assessed type
Access Control
The text was updated successfully, but these errors were encountered: