Closed c4-submissions closed 10 months ago
0xfoobar (sponsor) acknowledged
Seems like a duplicate of some other reports
GalloDaSballo changed the severity to QA (Quality Assurance)
Can be a gotcha, but because a owner can claim when they hold both tokens, it's QA
GalloDaSballo marked the issue as grade-c
Lines of code
https://github.com/code-423n4/2023-09-delegate/blob/main/src/DelegateToken.sol#L325
Vulnerability details
Impact
A malicious
PrincipalToken
owner can call theextend()
function through a front-running attack before transferring it to other users, causing the period to be extended, thereby locking other users' funds.According to the documentation:
Let's imagine the following scenario:
Alice thinks that the fund pool to which Bob's principal token belongs is profitable, and then purchases it from Bob. Through the transaction between the two, Alice got the principal token, which she only needs to wait until the expiration time to redeem it. At this time, Bob is a malicious user. He executes the
extend()
function through a front-running attack and extends the time. As a result, the principal token obtained by Alice cannot be redeemed. And because Alice does not own the delegate token, she cannot redeem it before expiration. This will cause Alice to funds are lockedProof of Concept
As we can see,
extend()
function can be called by theprincipalToken
owner or approverand the
withdraw()
will callStorageHelpers.revertInvalidWithdrawalConditions(delegateTokenInfo, accountOperator, delegateTokenId, delegateTokenHolder);
to check if expiry. Last , it will burn thePrincipal token
by callingStorageHelpers.burnPrincipal()
So:
Tools Used
manual
Recommended Mitigation Steps
I think this problem is similar to a slippage attack. We can add a parameter like
real_expiration_time
toPrincipalToken.transfer()
function. This parameter is specified by the user. When callingPrincipalToken.transfer()
function , callDelegateToken.getDelegateInfo()
to check whether it is the correctreal_expiration_time
.Assessed type
MEV