-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bin2chen - is_permissioned() It doesn't make sense to have permissions by default after Blacklisted expires. #47
Comments
Escalate This is intended behavior. The documentation (code comments) describes the intended behavior as follows: /// An enum to represent a user's permission for an action
///
/// - **Blacklisted** - The user cannot perform the action until after the provided expiration
/// - **Limited** - The user can perform the action while uses are remaining and before the provided expiration **for a permissioned action**
/// - **Whitelisted** - The user can perform the action until the provided expiration **for a permissioned action**
///
/// Expiration defaults to `Never` if not provided
#[cw_serde]
pub enum Permission {
Blacklisted(Option<Expiration>),
Limited {
expiration: Option<Expiration>,
uses: u32,
},
Whitelisted(Option<Expiration>),
} The documentation clearly states that the intended behavior for a blacklisted user is "The user cannot perform the action until after the provided expiration". So the user should be able to regain possibility to take actions after expiry which is the whole "vulnerability" described by this group of issues. |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
I don't see a problem here. NatSpec comments highlight that when a user is blacklisted, it is expected after a while to be able to regain the possibility to take action after the restriction expires. Planning to accept the escalation and invalidate the issue. |
The way I understand this sentence is. Suppose Example: Suppose But the problem is, if later the administrator decides to make the action But, since So the blacklisting mechanism, like the other two |
Hey @bin2chen66 , There is no default limitation state. As you can see on both the other roles, they also return true if they are not limited by expiration/uses. So effectively blacklist goes to the "default" state after expiration. |
hey @J4X-98 sorry , I didn't get what you meant. if strict=true current code: |
Hey @bin2chen66 , All the functions only return '!strict' if the user is not allowed by either their whitelist having expired or them not having any uses left. Otherwise the 2 others also return true by default. So there seem to only be 2 intended states:
And the implementation implements this as intended. The mediation you recommend would lead to the user still not having permissions after the blacklist expired, leading to a conflict with the description of the functionality. |
hey @J4X-98 |
Hey @bin2chen66 , What you recommend is returning
So as a result, the user regains access to strict functions when the blacklist has expired, which adheres to the behavior described by the documentation. Your proposed mitigation would result in the function always returning |
The statement below from this comment is incorrect:
The "default" state is no access and not upgraded access. Also, the issue is that when the blacklist expires, the user's permission is upgraded to the level of a non-expired whitelisted user. A non-expired whitelisted user has access even to strict permissioned actions. It does not make sense for a blacklisted user to become whitelisted on expiration. In the NFT ADO Contract, this would mean the expired blacklisted user can arbitrarily mint NFTs like the minter role. |
Hey, what you are missing is that a user can only be in two states as the current implementation works. These are either returning "The "default" state is no access and not upgraded access." -> The default state (which does not exist) you describe always returns false. So in your opinion, while a user is blacklisted, he should be able to access some functionalities that are not strict. Once the blacklist expires, the user should not be able to access anything anymore. This makes no sense and clashes with the documentation of the user regaining access once the blacklist has expired. It might be a future improvement to change the whole system to add more states that allow for more detailed control of the user's permissions. But for the current states, the contract can choose from there are only 2, and the implementation correctly uses one of those (the restricted one) while the user is blacklisted and the other one (no restrictions) once the blacklist has expired. This confirms the documentation, so there is no vulnerability; it is just a recommendation for future improvement. |
@cvetanovv although the comment is correct, it does not completely describe the current behavior of blacklisting.
After the blacklisting expires, the user gains whitelisted privileges. It's unclear just based on the comment if the dev team intends to increase a user's permissions to greater than a regular user once their blacklist expires. Also, isn't the dev team fixing the issue? Doesn't that confirm it? |
As described in multiple of the messages above there is no default behavior. There only is returning !strict or true and those are correctly used by the contract. Repeating the same invalid argument countless times does not make it more true. The judge has already twice confirmed that this issue is invalid, I don't see a reason to continue this discussion. |
Hi @J4X-98. Thank you for your opinions. I presented 2 new arguments which are:
The only way to know the intended functionality is to ask the dev team, especially since it is tagged as |
Hey, I think the comment pretty clearly describes the intended behavior "Blacklisted - The user cannot perform the action until after the provided expiration". The user should not be able to access permissioned functions while blacklisted and should be able to do so once the blacklist has expired. This is exactly what happens in the code. |
But does it make sense for a previously blacklisted user's privileges to be escalated to the level of a whitelisted user? The comment does not mention anything about that. It looks like an unintended privilege escalation. |
I really appreciate your input, @cu5t0mPeo. 🙏🏼 The sponsor has confirmed this as an issue @cvetanovv. It is an unintended privilege escalation. Sorry for all the discussion. Hope that's enough to validate the issue and reject the escalation. |
After the sponsor confirms that this is not an intended design, I will reject the escalation and leave the issue as is. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
The protocol team fixed this issue in the following PRs/commits: |
fix-reviews note: |
bin2chen
Medium
is_permissioned() It doesn't make sense to have permissions by default after Blacklisted expires.
Summary
in
is_permissioned()
, returnstrue
ifPermission::Blacklisted
has expiredit is not correct
Vulnerability Detail
in
is_permissioned()
to determine if a permission is granted.The current implementation returns
true
if the blacklist has expired, regardless ofstrict
.The following scenarios are problematic
action1
doesn't need permission at the beginning, i.e.: strict = falsealice
for 1 month, i.e.: alice has Permission::Blacklistedaction1
toaction1
requires permissions, i.e.: strict = trueis_permissioned(alice)
returns true, andalice
becomes permitted by default, which is not correct!It is reasonable to return
!strict
when it expires, just likeLimited
andWhitelisted
.Impact
Permission::Blacklisted
expires and returnstrue
, causing users to have permissions that shouldn't have them.Code Snippet
https://github.com/sherlock-audit/2024-05-andromeda-ado/blob/main/andromeda-core/packages/std/src/ado_base/permissioning.rs#L55
Tool used
Manual Review
Recommendation
The text was updated successfully, but these errors were encountered: