Closed c4-submissions closed 10 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as primary issue
Inadequate use of quota limit.
raymondfam marked the issue as high quality report
gus-staderlabs (sponsor) disputed
Though we see the value of this, we agree that this is not a KELPDAO protocol issue but an unintended consequence of the ETH blockchain design.
It is a nice to have, but not a bug in the system.
gus-staderlabs marked the issue as disagree with severity
manoj9april marked the issue as agree with severity
fatherGoose1 marked the issue as unsatisfactory: Invalid
I do not view this as a bug or anything to be fixed within Kelp's implementation. The likelihood that a griefer is willing to spend significant ETH gas fees to minorly inconvenience a depositor is low.
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTDepositPool.sol#L132-L134
Vulnerability details
Impact
The identified vulnerability in the
LRTDepositPool.sol
contract is a front-running issue in thedepositAsset
function. The nature of the vulnerability allows an attacker to observe a pending transaction intending to deposit assets close to the maximum limit and then execute a transaction with a higher gas price to be mined first. This could lead to the original transaction failing due to insufficient remaining deposit limit.https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTDepositPool.sol#L132-L134
In DeFi environments, front-running can be economically incentivized, especially if the attacker can benefit from blocking or influencing the outcome of other transactions. This issue can be particularly problematic in high-liquidity environments or during periods of significant network activity, where the timing of transactions can be critical for users.
Proof of Concept
Here's a typical scenario:
getAssetCurrentLimit()
has limited availability left.getAssetCurrentLimit()
, Bob would frontrun her with 1 wei ofdepositAmount
so that Alice'sdepositAmount
of10 ether
ended up 1 wei greater than10 ether - 1
ofgetAssetCurrentLimit()
.getAssetCurrentLimit()
, Bob would frontrun her with0.5 ether + 1
ofdepositAmount
just enough to make Alice's transaction revert.Tools Used
Manual
Recommended Mitigation Steps
getAssetCurrentLimit(asset)
) falls below this threshold, the transaction would revert unless certain conditions are met (like the sender having a non-zero balance ofrsethToken
). This threshold should be carefully chosen based on the typical transaction sizes and the economics of your system.msg.sender
has a non-zero balance ofrsethToken
, you allow users who are already participants in the system (and thus potentially have a vested interest) to make smaller deposits. This can be seen as a form of loyalty or trust system, where existing users are given more flexibility.depositAsset
function would look something like this to use up the remaininggetAssetCurrentLimit(asset)
conditionally:Assessed type
DoS