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
The pool holdings of Insurance (publicCollateralAmount and bufferCollateralAmount) is in WAD (18 decimals) but it's used as a raw token value in drainPool
// amount is a mix of pool holdings, i.e., 18 decimals// this requires amount to be in RAW! if tracerMarginToken has > 18 decimals, it'll break, < 18 decimals will approve too much
tracerMarginToken.approve(address(tracer), amount);
// this requires amount to be in WAD which is correct
tracer.deposit(amount);
Impact
If tracerMarginToken has less than 18 decimals, the approval approves orders of magnitude more tokens than required for the deposit call that follows.
If tracerMarginToken has more than 18 decimals, the deposit that follows would fail as fewer tokens were approved, but the protocol seems to disallow tokens in general with more than 18 decimals.
Recommended Mitigation Steps
Convert the amount to a "raw token value" and approve this one instead.
The text was updated successfully, but these errors were encountered:
The issue is correct in pointing out that the wrong approve amount is used, however disagree with the severity.
It is common practice to approve the maximum amount of tokens for a contract to spend already. This bug simply allows more tokens to be approved (to a trusted contract in the system), than was intended. This is only exploitable if paired with another bug in the Tracer contracts. As is, no users would be affected.
Handle
cmichel
Vulnerability details
The pool holdings of
Insurance
(publicCollateralAmount
andbufferCollateralAmount
) is in WAD (18 decimals) but it's used as a raw token value indrainPool
Impact
If
tracerMarginToken
has less than 18 decimals, the approval approves orders of magnitude more tokens than required for thedeposit
call that follows.If
tracerMarginToken
has more than 18 decimals, thedeposit
that follows would fail as fewer tokens were approved, but the protocol seems to disallow tokens in general with more than 18 decimals.Recommended Mitigation Steps
Convert the
amount
to a "raw token value" and approve this one instead.The text was updated successfully, but these errors were encountered: