-
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
Inexistent Slippage Protection #17
Comments
The finding looks valid in that a caller may purchase the incorrect amount if the price is changed, this is also a mitigatable MEV vector which can be avoided via a router / slippage check Thinking Med is appropriate due to leak of value |
m19 marked the issue as sponsor disputed |
We disagree with the validity: we calculate the value when buying/selling a bond NFT at the last epoch using the metadata of the NFT, so there isn’t a risk of slippage vulnerability. If a tx takes a long time to confirm, when buying you are expecting to receive more KIBT for the time that has passed since. And same for buying: you are expected to pay extra for the NFT. We think it's up to the user to set a sensible gas price to avoid paying a different price than expected. |
Thanks for the feedback! The fee that your protocol applies is entirely up to your discretion (no limitations to invocation) and as such the fee can change between a transaction's submission and a transaction's execution. While the scenario may be unlikely, it is valid and can result in unexpected loss-of-value for the end user when invoking Gas fees are not the only issue affecting when a transaction gets executed with regard to Based on the above:
I believe that slippage checks need to be introduced to the protocol. |
Based on @alex-ppg's comments I definitely would remove the sponsor-disputed label and just disagree with the severity. We still think it's an extremely unlikely scenario where the fee has to be changed between a seller's tx submission onchain and the tx confirmation. But we have to acknowledge that technically these scenarios could happen in the current implementation where a seller receives less than expected and a buyer pays more than expected. |
m19 marked the issue as disagree with severity |
Generally speaking lack of In this case, I believe that bondValue can change for 3 reasons:
@m19 lmk if I misunderstood and if you think the changes will not impact prices |
Setup this test to investigate the changes of price over time (due to network fluctuation as well as interest) function test_sellBond_PokeValue() public {
_KUMASwap.sellBond(1);
skip(300 days);
IKUMABondToken.Bond memory bond_ = _bond;
bond_.issuance = uint64(block.timestamp);
_KUMABondToken.issueBond(address(this), bond_);
_KUMASwap.sellBond(2);
bond_.issuance = uint64(block.timestamp);
_KUMABondToken.issueBond(address(this), bond_);
uint256 baseValue = _KUMASwap.getBondBaseValue(2);
assertEq(baseValue, uint256(10 ether).wadToRay().rayDiv(_YIELD.rayPow(300 days)), "Exp value");
skip(60 minutes);
_KUMASwap.sellBond(3);
assertEq(baseValue, _KUMASwap.getBondBaseValue(3), "60 mins");
} I can get the test to fail (value are not the same), when I set the skip to 1 day function test_sellBond_PokeValue() public {
_KUMASwap.sellBond(1);
skip(300 days);
IKUMABondToken.Bond memory bond_ = _bond;
bond_.issuance = uint64(block.timestamp);
_KUMABondToken.issueBond(address(this), bond_);
_KUMASwap.sellBond(2);
bond_.issuance = uint64(block.timestamp);
_KUMABondToken.issueBond(address(this), bond_);
uint256 baseValue = _KUMASwap.getBondBaseValue(2);
assertEq(baseValue, uint256(10 ether).wadToRay().rayDiv(_YIELD.rayPow(300 days)), "Exp value");
skip(1 days);
_KUMASwap.sellBond(3);
assertEq(baseValue, _KUMASwap.getBondBaseValue(3), "1 day");
} The difference is there but marginal |
The difference seems to be extremely contained. >>> 9606919193649876111600712464 / 9606919193649876111125169201 * 100
100.0
>>> (9606919193649876111600712464 - 9606919193649876111125169201) / 9606919193649876111125169201 * 100
4.9500079413005956e-18 With the information that I have, considering that the finding has validity, but in the majority of cases will be extremely limited, I believe QA Low to be the most appropriate severity |
L |
GalloDaSballo changed the severity to QA (Quality Assurance) |
GalloDaSballo marked the issue as grade-a |
GalloDaSballo marked the issue as selected for report |
GalloDaSballo marked the issue as not selected for report |
Lines of code
https://github.com/code-423n4/2023-02-kuma/blob/main/src/kuma-protocol/KUMASwap.sol#L166
https://github.com/code-423n4/2023-02-kuma/blob/main/src/kuma-protocol/KUMASwap.sol#L224
Vulnerability details
Impact
All bond evaluations are dynamic within the
KUMASwap::sellBond
andKUMASwap::buyBond
functions, however, they operate with token IDs as input arguments and do not perform any sanitization on the amount ofKIB
tokens minted or burned respectively.In turn, this can lead to the user receiving fewer funds than they expected for the sale of a bond or the user paying a higher amount of
KIB
tokens than they were willing to. As the blockchain state between a transaction's submission to the network and a transaction's execution can differ, this is a significant issue commonly known as a slippage vulnerability.The issue is especially applicable in the case of a purchase as the evaluation of a bond increases per second based on the implementation of
KUMASwap::_getBondValue
.Proof of Concept
N/A
Tools Used
Manual review.
Recommended Mitigation Steps
The codebase should follow the DEX paradigm of an additional parameter signaling the minimum output / maximum input a user is willing to provide for a particular swap. In the case of a sale, the value should be utilized as a minimum amount of
KIB
tokens they will receive. In the case of a purchase, the value should be utilized as a maximum instead. We should note that regardless of the bond's evaluation, the interest accrued in theKIBToken
(getUpdatedCumulativeYield
) can also be influenced between a transaction's submission and a transaction's execution in the network by invokingKIBToken::refreshYield
.As an additional point, fees in the
KUMASwap
contract can be adjusted between a transaction's submission and a transaction's execution rendering the slippage check during thesellBond
function applicable as well.The text was updated successfully, but these errors were encountered: