Skip to content
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

Unable to change token approval when tokenAddress changed #215

Open
code423n4 opened this issue Nov 24, 2021 · 2 comments
Open

Unable to change token approval when tokenAddress changed #215

code423n4 opened this issue Nov 24, 2021 · 2 comments
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Something isn't working sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue

Comments

@code423n4
Copy link
Contributor

Handle

gzeon

Vulnerability details

Impact

Lock manager and beneficiary can call approveBeneficiary to set the allowance of tokenAddress. However, if tokenAddress is changed by updateKeyPricing, they will not be able to revoke the token approval set previously.

Proof of Concept

https://github.com/unlock-protocol/unlock/blob/025ed6ab14c10cc41d7fe14ab49a051647211adb/smart-contracts/contracts/mixins/MixinLockCore.sol#L226

Recommended Mitigation Steps

  function approveBeneficiary(
    address _spender,
    address _tokenAddress,
    uint _amount
  ) public
    onlyLockManagerOrBeneficiary
    returns (bool)
  {
    return IERC20Upgradeable(_tokenAddress).approve(_spender, _amount);
  }
@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Nov 24, 2021
code423n4 added a commit that referenced this issue Nov 24, 2021
@julien51
Copy link
Collaborator

I am actually not sure they should revoke these. Once the lock has approved a 3rd party address to withdraw some funds from the lock, changing the currency of the lock should not necessarily have an impact on the previous approval.
Example: my lock charges 10 DAI per membership. I allow a designer to withdraw up to 100 DAI. Eventually I switch to USDC, but I don't think I should prevent the designer from withdrawing their 100DAI.

@julien51 julien51 added sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue and removed sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons labels Dec 11, 2021
@0xleastwood
Copy link
Collaborator

I think the sponsor is right here. Marking as non-critical.

@0xleastwood 0xleastwood added 0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Jan 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 (Non-critical) Code style, clarity, syntax, versioning, off-chain monitoring (events etc), exclude gas optimisation bug Something isn't working sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue
Projects
None yet
Development

No branches or pull requests

3 participants