Closed code423n4 closed 1 year ago
Picodes marked the issue as duplicate of #356
Picodes marked the issue as duplicate of #488
Picodes marked the issue as satisfactory
Picodes marked the issue as partial-50
Picodes changed the severity to 3 (High Risk)
Lines of code
https://github.com/code-423n4/2023-05-ajna/blob/main/ajna-core/src/PositionManager.sol#L170-L176
Vulnerability details
Impact
Anyone can memorialize other users' positions with a given NFT and transfer ownership of the LP to the PositionManager contract.
This is an unathorized use of other user assets by any person.
Proof of Concept
This POC shows the lack of access control validation for
memorializePositions()
, which is in scope for this issue, as well as some additional considerations to check on out of scope resources.PositionManager::memorializePositions()
does not perform any check to see if the user can interact with the pool/token (as other functions do with themayInteract
modifier):Link to code
memorializePositions()
callspool.transferLP
, which doesn't validate theowner
parameter either:The base implementation of the abstract contract
Pool
does not perform any check:Link to code
The
LPActions
library used fortransferLP()
doesn't perform any check on theownerAddress_
to see if themsg.sender
is allowed to call it:Link to code
Coded POC
This test shows how anyone can call
PositionManager::memorializePositions()
on behalf of another person. It is based on the testtestMemorializePositions()
, with the addition of thechangePrank(address(666));
line to demonstrate the issue.Add this test to
ajna-core/tests/forge/unit/PositionManager.t.sol
and runforge test -m "testMemorializePositions_Anyone"
:Tools Used
Manual Review
Recommended Mitigation Steps
Validate that the user can interact with the corresponding pool/token:
Additionally check if a similar validation should be added to the
transferLP()
of the libraryLPActions.sol
or the abstractPool.sol
.Assessed type
Access Control