setRole
Function Incorrectly Assigns _safe.lead
without Validating enabled
Parameter
#41
Labels
setRole
Function Incorrectly Assigns _safe.lead
without Validating enabled
Parameter
#41
Github username: @0xmahdirostami
Twitter username: 0xmahdirostami
Submission hash (on-chain): 0xbf10b39a27d651c17d6761180193456a8268a6128535dc785370130b083e2c69
Severity: high
Description:
Description:
The
setRole
function assigns the_safe.lead
attribute to a user if the role is related to safe leadership (SAFE_LEAD
,SAFE_LEAD_EXEC_ON_BEHALF_ONLY
,SAFE_LEAD_MODIFY_OWNERS_ONLY
). However, the function fails to check theenabled
boolean parameter before updating_safe.lead
. This can lead to unauthorized access control issues where users might be improperly assigned as safe leads.Impact:
This oversight can result in unauthorized access control, allowing users to be incorrectly recognized as safe leads even if their role was meant to be disabled. This compromises the security and integrity of the system.
Proof of Concept (PoC):
Consider the current implementation of the
setRole
function:In the above code,
_safe.lead
is assigned touser
without checking ifenabled
istrue
. This means users could inadvertently be granted lead roles.Mitigation:
enabled
Parameter:Ensure the
enabled
parameter is checked before updating_safe.lead
.If
enabled
isfalse
, and the user does not have any other lead roles,_safe.lead
should be set toaddress(0)
.Updated
setRole
function:By including the
enabled
parameter check and ensuring that lead roles are properly revoked, this updated function maintains the integrity of access control, preventing unauthorized role assignments.The text was updated successfully, but these errors were encountered: