You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dear saucepoint:
I find that a potential risk can arise from the possible parameter manipulation of the function afterSwap(). Malicious attackers can input any value of parameters key and params to manipulate intermediate variables and the key stop loss operation in the internal function fillStopLoss() can also be influenced.
I think critical hooks should all be protected which can only be invoked by pool manager. For example, the afterInitialize() is protected in your StopLoss contract. However, the afterSwap() isn't. So adding a simple protective modifier may be good to avoid potential risk.
Hope it helps and glad to discuss further.
The text was updated successfully, but these errors were encountered:
Dear saucepoint:
I find that a potential risk can arise from the possible parameter manipulation of the function afterSwap(). Malicious attackers can input any value of parameters key and params to manipulate intermediate variables and the key stop loss operation in the internal function fillStopLoss() can also be influenced.
I think critical hooks should all be protected which can only be invoked by pool manager. For example, the afterInitialize() is protected in your StopLoss contract. However, the afterSwap() isn't. So adding a simple protective modifier may be good to avoid potential risk.
Hope it helps and glad to discuss further.
The text was updated successfully, but these errors were encountered: