Closed c4-bot-7 closed 6 months ago
MarioPoneder marked the issue as duplicate of #69
MarioPoneder marked the issue as not a duplicate
MarioPoneder marked the issue as duplicate of #205
MarioPoneder changed the severity to QA (Quality Assurance)
MarioPoneder marked the issue as grade-b
MarioPoneder marked the issue as grade-c
This previously downgraded issue has been upgraded by MarioPoneder
MarioPoneder marked the issue as satisfactory
Lines of code
https://github.com/code-423n4/2024-02-uniswap-foundation/blob/491c7f63e5799d95a181be4a978b2f074dc219a5/src/UniStaker.sol#L327
Vulnerability details
Bug Description
In the
UniStaker
smart contract, there is astakeOnBehalf
function and other functions that can be called on behalf of a user. If a user wants UNI to be staked for them from another address, they sign a message and pass the generated signature, allowing the other address to call thestakeOnBehalf
function. The issue is that the generated signature is perpetual and can be used at any time.Proof-of-Concept
Alice (EOA) trusts Bob (EOA) and provides a signature for Bob to call the
stakeOnBehalf
function and pre-approve theUniStaker
smart contract. After that, she asks Bob not to send the transaction because she changed her mind. UniStaker.sol#L391-L399Six months pass, and Bob becomes malicious. Bob can stake on behalf of Alice even after six months because the signature for EOA is not revocable.
Impact
If a user provides a signature allowing someone else to stake on their behalf using the
UniStaker
smart contract but later decides not to stake, there is a risk that the other party could still use that signature to stake on behalf of the user at any time in the future.Tools Used
Manual
Recommended Mitigation Steps
Consider adding a deadline value to
STAKE_TYPEHASH
and other type hashes related toonBehalf
calls:Additionally, ensure that the
block.timestamp
value is less than the current_deadline
.Assessed type
Context