Closed c4-bot-2 closed 4 months ago
Picodes marked the issue as duplicate of #620
Picodes changed the severity to 2 (Med Risk)
Picodes marked the issue as satisfactory
Picodes changed the severity to QA (Quality Assurance)
This previously downgraded issue has been upgraded by Picodes
ballotNames now include all provided proposal arguments https://github.com/othernet-global/salty-io/commit/39921b4a25041c7ac4e9b5279e12bb2ec518140b
Picodes marked the issue as not a duplicate
Picodes marked the issue as duplicate of #620
Lines of code
https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/Proposals.sol#L240-L246 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/DAO.sol#L219-L228 https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/dao/DAO.sol#L155-L215
Vulnerability details
Summary
The ballotName check in
Proposals::_possiblyCreateProposal()
can be exploited to DOSproposeSetContractAddress()
&proposeWebsiteUpdate()
proposals.Vulnerability Details
Where a ballot, requiring a confirmation vote, is created with a genuine ballotName such as
setContract:pricefeed1
; a malicious user can create another ballot with ballotNamesetContract:pricefeed1_confirm
.This will prevent the initial ballot from being finalized, even if it has gathered enough votes, because a confirmation proposal cannot be created via
_finalizeApprovalBallot
. Confirmation proposals are created with_confirm
appended to the end of the initial ballotName; i.e.setContract:pricefeed1
+_confirm
; where it will hit the ballotName check:Because there is no way to cancel a proposal; this also blocks any future attempts to update the address for
pricefeed1
. In the same way, address updates topricefeed2
,pricefeed3
&accessManager
can be prevented.Proposals for updating the website can be blocked in a very similar way by creating an identical proposal using the same
newWebsiteURL
and appending_confirm
which will create a proposalsetURL:newWebsiteURL_confirm
and block the automatic confirmation proposal creation.POC
Add the test function below to
DAO.t.sol
and run:Impact
If any of the critically important Access Manager or Price Feed contract addresses were to become compromised or otherwise unusable; simply not being able to update them represents a potential systemic collapse of the protocol. Further, given how price aggregation works in the protocol using three sources; if a malicious user is able to ensure one external source remains off, they could potentially manipulate the internal pool feed using large money inflows / outflows such that they gain an advantage.
Tools Used
Manual Review Foundry Testing
Recommendations
Update the logic for naming proposals such that they cannot be mimicked by user entering a string. To solve the problem, an
enum
could be used as the input parameter, representing the contract the user is proposing to update. The protocol can then map to the correct name so the rest of the logci needn't be updated.Assessed type
DoS