-
Notifications
You must be signed in to change notification settings - Fork 14
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
Complete halt under certain circumstances #509
Comments
raymondfam marked the issue as sufficient quality report |
hieronx (sponsor) acknowledged |
hieronx marked the issue as disagree with severity |
Acknowledged but very unlikely, and still protected through both currency addition checks and the fact that it would first need to be deployed on a centralized L1/L2 for this to even be feasible. |
I believe this is out-of-scope due to (4) but I think this is something nice to be documented. Downgrading to Low/QA. |
gzeon-c4 changed the severity to QA (Quality Assurance) |
gzeon-c4 marked the issue as grade-a |
gzeon-c4 marked the issue as grade-b |
Hey, @gzeon-c4, kudos for the feedback 🎉
As of this, I know, I haven't included any details on why the system is completely halt by saying the following:
The system is halt, since no deposits are being made => solver mechanism has to be initiated in order to get the submission under a defined set of restrictions for the linear maximization problem. Since the deposits are paused, it's unlikely that the solver will provide a solution without breaking those restrictions, because in order to finalize withdrawal requests the system rely on its reserves + new investments.
With this, I 100% agree with you, but it's not like: adding fee-on-transfer token will be break the system. Since in this case, both Governance and the devs behind Centrifuge clearly are aware about the limits behind the system.
The impact here is critical, however, the likelihood is low/medium. Based on the impact and the likelihood I believe the severity could be raised up to the "Medium". The similar evaluation has been handled here: code-423n4/2023-07-axelar-findings#267 (comment) , but in this case the critical impact occurs, in case of deployer's EOA being compromised. @hieronx , sorry for tagging, but your opinion is also much appreciated to fairly decide the contribution behind this issue!!! Thanks a lot for looking into it! I just simply wanna make sure, that this issue will be clearly documented in the report, so that the devs and Governance members will be aware of it. |
I still believe this is low risk as this require the governance to add an incompatible token, and there is a lot of way to create a token that is incompatible with various part of centrifuge. The Centrifuge chain may also have the ability to ignore any malicious deposit cancelation request as it is a blackbox. |
Gotcha, thanks a lot! |
Lines of code
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/LiquidityPool.sol#L220-L226
Vulnerability details
Vulnerability Details
As you already know, some of the native gas tokens do not have the logic implemented for
.permit()
whatsoever, but they do have non-revertingfallback()
in order to accept the native currency.Having the context needed, we can finally look into the
requestDepositWithPermit()
:ERC20PermitLike(asset).permit(...)
will be processed further.Impact
Proof of Concept
For the case with complete halt an attacker could simply:
For all other described cases, the PoC is intuitive.
Recommended Mitigation Steps
Assessed type
Context
The text was updated successfully, but these errors were encountered: