Platform: Code4rena
Start Date: 14/03/2024
Pot Size: $49,000 USDC
Total HM: 3
Participants: 51
Period: 7 days
Judge: 3docSec
Id: 350
League: ETH
Rank: 26/51
Findings: 1
Award: $36.34
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: 0xmystery
Also found by: 0xbrett8571, 0xhacksmithh, 7ashraf, Bigsam, Circolors, IceBear, Jorgect, Koala, Limbooo, SBSecurity, Tigerfrake, ZanyBonzy, aycozynfada, cheatc0d3, cryptphi, d3e4, doublespending, foxb868, gpersoon, imare, jesjupyter, lsaudit, robriks, shealtielanz, y4y
36.3397 USDC - $36.34
The removeOwnerAtIndex
function allows owners to be removed. The function can only be called by the owners or the contract itself. The issue is that owners can evade this removal by frontrunning the calls to the function and removing the owner that wants to remove them, thereby evading and consequently griefing other owners in the process.
The removeOwnerAtIndex
holds the onlyOwner
modifier which checks if the caller is an owner. Hence, only the owners can call.
function removeOwnerAtIndex(uint256 index) public virtual onlyOwner { bytes memory owner = ownerAtIndex(index); if (owner.length == 0) revert NoOwnerAtIndex(index); delete _getMultiOwnableStorage().isOwner[owner]; delete _getMultiOwnableStorage().ownerAtIndex[index]; emit RemoveOwner(index, owner); }
By frontrunning the call to the function, and passing other owner's address, the to-be-removed owner can grief and potentially avoid being removed as an owner.
removeOwnerAtIndex
function passing in index 2 to remove User B from owner's list._addOwnerAtIndex
to remove User A if user A gets readded.Manual code review
A potential solution is limiting the calls to the removeOwnerAtIndex
function to only the contract.
Another potential solution is removing the function completely, as it introduces griefing vectors.
Other
#0 - c4-pre-sort
2024-03-21T22:04:37Z
raymondfam marked the issue as sufficient quality report
#1 - c4-pre-sort
2024-03-21T22:04:48Z
raymondfam marked the issue as duplicate of #18
#2 - raymondfam
2024-03-21T22:06:01Z
Mimicking the exploit path of #57.
#3 - c4-pre-sort
2024-03-22T22:32:14Z
raymondfam marked the issue as duplicate of #22
#4 - c4-pre-sort
2024-03-22T23:28:47Z
raymondfam marked the issue as not a duplicate
#5 - c4-pre-sort
2024-03-22T23:29:15Z
raymondfam marked the issue as duplicate of #57
#6 - c4-judge
2024-03-27T08:53:08Z
3docSec marked the issue as not a duplicate
#7 - c4-judge
2024-03-27T08:53:36Z
3docSec marked the issue as duplicate of #18
#8 - c4-judge
2024-03-27T10:20:16Z
3docSec changed the severity to QA (Quality Assurance)
#9 - c4-judge
2024-03-27T10:22:53Z
3docSec marked the issue as grade-a
#10 - 3docSec
2024-03-28T09:00:03Z
Hi @ZanyBonzy ,
I see your points, but all attacks require the attacker to have been previously added as a trusted owner, so even the most sophisticated attack can only come out of a serious mistake of the user who leaked the keys to their wallet. It can't be more than QA under this consideration.
#11 - PaperParachute
2024-03-28T13:55:30Z
Closing while discussing internally
#12 - 3docSec
2024-03-28T21:34:50Z
Hi @ZanyBonzy sorry for the confusion. The issue was reopened accidentally while I was confirming with the C4 team whether QA findings like this one need to be open to be eligible for awards.
The answer is no: as soon as there is a grade-a or grade-b label, the findings will receive a share of the QA pot. So the issue can stay closed without impacting awarding