-
Notifications
You must be signed in to change notification settings - Fork 0
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
Malicios Operator can utilize a malicios DSS and an overleveraged vault to frontrun an honest DSS's slashing request to protect its funds #27
Comments
MiloTruck changed the severity to QA (Quality Assurance) |
This is a good attack scenario, but unfortunately it relies on speculation of future code:
The current Note that slashing handlers are whitelisted by the protocol's |
MiloTruck marked the issue as grade-b |
Hello @MiloTruck, Thank you for judging ser. I believe this submission still correctly indentifies that it is not possible to deploy a slashing handler that does anything else than just burn the slashed tokens. So at the very least this is a limitation of the current code and potential high severity vulnerability if the limitation is ignored or not noticed. In other words, the currently deployed slashing handler does not make the protocol vulnerable to this attack, but the rest of the system is limited to only using this slashing handler because of the attack vector. Because of this I still believe this should be at least medium severity. Also, I would like to point out the root cause being the ability of any DSS to specify the slashing of 100% of funds and vaults being overleveraged, these two would make the deployment of slashing handlers with custom logic not possible, and impair future development of the protocol. According to C4 docs that should make this eligible to be in scope. Also, the Karak Docs say that slashing handlers that do not burn the tokens, but distribute the funds to the affected parties can be deployed in the future. If this attack is used the funds also won't reach the affected parties. So, considering it likely that a slashing handler that is different to the current one and that does not burn the tokens is deployed, it makes this attack vector possible and this should be high severity... |
I would like to refer you to the following C4 ruling: code-423n4/org#72 Additionally, if this were to happen, it is reasonable to assume the slashing veto committee would simply veto the slashing request from the operator as it is obviously malicious. This remains as QA. |
Yes, I read the verdict I believe it is still medium or high severity. It is the same text as the link to the C4 docs that I sent in my escalation comment... It doesn't exclude the finding from being in scope or medium/high severity
Both Karak docs and the code comments suggest that such custom logic slashing handlers will be deployed eventually. The dev team will have to either not deploy those slashing handlers or make changes to the codebase to address this vulnerability before deploying them. To your comment:
An attacker that attempts this will have knowledge of how to deploy and run an Operator and a DSS and attempt a malicios action(exploit) against an honest DSS with potential loss of funds for it's users. So, I think it is fair to assume that the attacker will be well funded and able to create a decoy "honest" DSS to bypass the veto committee with a non-negligible probability. That should be of concern to the protocol team. If the veto committee does not veto this, then it will certainly lead to loss of funds and have 0 impact on the attacker. The mitgation steps that I recommend, at least guarantee loss of funds for the attacker no matter if the veto committee notices the malicios slashing event. |
Lines of code
https://github.com/code-423n4/2024-07-karak/blob/main/src/Core.sol#L262
https://github.com/code-423n4/2024-07-karak/blob/main/src/entities/SlasherLib.sol#L174
https://github.com/code-423n4/2024-07-karak/blob/main/src/SlashingHandler.sol#L57
Vulnerability details
Impact
By design, the protocol allows vaults to be overleveraged, meaning they can be staked to more than 1 DSS. Also, if an operator is found to be malicios a DSS can slash the funds of it's vault. Furthermore, anyone can register as a DSS.
This means that a malicios operator can utilize a custom DSS with 100% slashing to stake his funds and then also stake his funds to an honest DSS. The operator would attempt a malicios operation on the DSS, which would result in a slashing event being submitted by the honest DSS. The operator can then monitor the mempool and frontrun the slashing event transaction by submitting a slashing event from his own DSS for 100% as well.
The default implementation of the slashing handler in the protocol burns the slashed funds, however, it is common practice in these types of systems, to distribute the slashed funds to honest operators, by for example sending them first to a ledger on the DSS side. Other slashing handlers are expected to be made.
The attacker would select an asset with a slashing handler that would allow him to return the funds slashed by his own DSS. This way the attacker can refund his own funds. This is assuming that the veto committee does not recongnize that the operator is working with his own DSS, which can be very difficult to do, if the DSS is designed to appear honest, considering another honest DSS would be slashing this operator as well, it will be easy to mistake the malicios slashing for an honest one.
Proof of Concept
The protocol allows anyone to register as a DSS:
https://github.com/code-423n4/2024-07-karak/blob/main/src/Core.sol#L262
The
maxSlashablePercentageWad
can be up to 100%, meaning a DSS can slash up to 100% of a staked operator's funds:https://github.com/code-423n4/2024-07-karak/blob/main/src/entities/SlasherLib.sol#L174
With Constants.MAX_SLASHING_PERCENT_WAD = 100%.
The default SlashingHandler implementation is to burn the slashed funds, however it is not uncommon for such protocols to distribute slashed funds to honest operators. So, considering this could be the case, that logic would be implemented as stated by the comments:
https://github.com/code-423n4/2024-07-karak/blob/main/src/SlashingHandler.sol#L57
So, considering a DSS that allows an operator to be overleveraged, it will be susceptible to this attack.
The attacker would follow these steps:
As a result the honest DSS would slash 0 funds, since the operator would have remove his own funds via the malicios DSS slashing request.
Tools Used
Manual Review
Recommended Mitigation Steps
This would be complicated to solve, however options are requiring an operator to always have a non-leveraged stake in a DSS. This way they will always lose funds should they attempt this attack vector. Or instead limit slashing to less than 100% of vault stake, for example 80% max slashing for a DSS.
Assessed type
Other
The text was updated successfully, but these errors were encountered: