search

sherlock-audit / 2024-02-jala-swap-judging

6 stars 4 forks source link

jasonxiale - issues related to Fan token paused. #222

Closed sherlock-admin closed 6 months ago

sherlock-admin commented 6 months ago

jasonxiale

medium

issues related to Fan token paused.

Summary

  1. Since Fan Tokens like BAR and PSG are supported in the system , those type of token can be paused, according to the source code, if the token is puased, the token can't be transferred anymore.
  2. Our system can wrap those Fan Tokens, and even if the Fan Token is paused, the wrapped token can still be transferred.

In such case, there might some issues.

Vulnerability Detail

  1. A technical user can use the wrapped token as a safe harbor to reduce the risk of the Fan Token pused. After Alice got a BAR token, she can call ChilizWrappedERC20.depositFor to convert her BAR to WBAR. In the case of BAR is paused, she can use WBAR to swap to other token like WPSG or ETH to reduce her loss
  2. add liquidity: In the case of a non-technical user calls JalaMasterRouter.wrapTokensAndaddLiquidity to add liquidity, if BAR is paused, the user won't remove his liquidity because when calling JalaMasterRouter.removeLiquidityAndUnwrapToken, the function will calls ChilizWrapperFactory.unwrap in JalaMasterRouter.sol#L136 and ChilizWrapperFactory.unwrap will call ChilizWrappedERC20.withdrawTo in ChilizWrapperFactory.sol#L26. And in ChilizWrappedERC20.withdrawTo the function will revert in ChilizWrappedERC20.sol#L52 But for a technical user, he can find the wrapped token pair address, and calls router.removeLiquidity with the wrapped token as parameter. In such case, after he receives the wrapped token, he can swap the transfer the wraped token to other unpaused token.

Impact

By current design, non-technical user suffer more risk.

Code Snippet

https://github.com/sherlock-audit/2024-02-jala-swap/blob/030d3ed54214754301154bce0e58ea534100a7e3/jalaswap-dex-contract/contracts/utils/ChilizWrappedERC20.sol#L33-L60

Tool used

Manual Review

Recommendation

nevillehuang commented 6 months ago

Invalid, external admins are trusted not to be malicious. However, there seem to be some conflicting information

Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

Trusted

This admins can indeed DoS certain core functions though and the read.me does say the following:

In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

Please submit any issue that could potentially compromise the JalaSwap protocol.

Since there is no rule catering to the conflicting information, I will have to put external admin trust assumptions with more significance see point 5. here.

  1. External Admin trust assumptions:
    1. When external-admin=trusted, issues related to these external admins being able to rug protocol users is not a valid issue. (Example: Aave governance has the intention of rugging Index Protocol))