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
Missing ERC1155 Token ID Handling in Withdrawal Logic Leading to inability to withdraw collateral
Summary
The withdraw function in the CollateralEscrowV1 contract fails to account for the token ID when withdrawing ERC1155 tokens. While the function supports generic collateral withdrawals, it lacks logic to handle ERC1155 tokens that require both a token address and a token ID to uniquely identify a specific asset type.
This poses a serious issue because the protocol supports ERC 1155 to be deposited as collateral as seen in the deposit function in collateralManager.sol;
In CollaterEscrow.sol: 85, the withdrawal logic assumes that specifying only the collateral address and amount is sufficient for all token types. This assumption breaks for ERC1155 tokens, which require a token ID to differentiate between various token types managed by the same contract.
The collateralBalances mapping uses the _collateralAddress as a key without differentiating between token IDs.
The function _withdrawCollateral lacks a parameter or logic for handling ERC1155 token IDs.
External pre-conditions
ERC1155 tokens can represent multiple asset types (e.g., token ID 1 for "Gold" and 2 for "Silver") within the same contract.
Without the token ID, the contract cannot identify which ERC1155 token type to withdraw, leading to potential errors or unintended behavior.
Users may deposit ERC1155 tokens as collateral using the _deposit function but find themselves unable to withdraw them correctly due to the missing token ID logic.
Attack Path
No response
Impact
Improper handling of ERC1155 tokens can result in asset loss. This leads to inability to withdraw collateral
Protocol Non-Compliance: The withdrawal function deviates from the ERC1155 standard, potentially breaking integrations
PoC
A user deposits an ERC1155 token as collateral (e.g., token ID = 1).
The user(lender) or protocol attempts to withdraw the collateral using the withdraw function.
The function fails or withdraws an unintended token because the token ID is not specified or handled.
The user cannot recover their specific collateral.
Mitigation
Update the withdraw Function:
Add a uint256 _tokenId parameter to the withdraw function and propagate it to _withdrawCollateral and any relevant logic.
AND
Update the withdraw Function:
Add a uint256 _tokenId parameter to the withdraw function and propagate it to _withdrawCollateral and any relevant logic.
Brisk Sapphire Chipmunk
High
Missing ERC1155 Token ID Handling in Withdrawal Logic Leading to inability to withdraw collateral
Summary
The withdraw function in the CollateralEscrowV1 contract fails to account for the token ID when withdrawing ERC1155 tokens. While the function supports generic collateral withdrawals, it lacks logic to handle ERC1155 tokens that require both a token address and a token ID to uniquely identify a specific asset type.
This poses a serious issue because the protocol supports ERC 1155 to be deposited as collateral as seen in the deposit function in collateralManager.sol;
Root Cause
In CollaterEscrow.sol: 85, the withdrawal logic assumes that specifying only the collateral address and amount is sufficient for all token types. This assumption breaks for ERC1155 tokens, which require a token ID to differentiate between various token types managed by the same contract.
The _withdrawCollateral function does not accept or process a tokenId, leaving it incapable of properly handling ERC1155 tokens.
https://github.com/sherlock-audit/2024-11-teller-finance-update/blob/main/teller-protocol-v2-audit-2024/packages/contracts/contracts/escrow/CollateralEscrowV1.sol#L85
Internal pre-conditions
External pre-conditions
Attack Path
No response
Impact
PoC
Mitigation
Update the withdraw Function:
Add a uint256 _tokenId parameter to the withdraw function and propagate it to _withdrawCollateral and any relevant logic.
AND
Update the withdraw Function:
Add a uint256 _tokenId parameter to the withdraw function and propagate it to _withdrawCollateral and any relevant logic.
The text was updated successfully, but these errors were encountered: