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
{{ message }}
This repository has been archived by the owner on May 26, 2023. It is now read-only.
Maximal approvals remain for the AssetManager's adapters and tokens after removal
Summary
While adding an adapter and a token to the AssetManager the system provides for the unlimited approvals for the current list of tokens and markets correspondingly, while the removal of the adapter and the token does not clear these approvals, which can be exploited thereafter as the contract balance does hold intermediary funds.
Vulnerability Detail
If the adapter or the token are being removed due to it being found to be malicious or contain a critical issue, treating downstream systems, currently there is no way to remove the exposure to it. This allowance can be exploited to drain AssetManager's balance.
That's a long term threat as market adapter or token being removed keep unlimited allowances forever as there is no mechanics to remove or limit those. I.e. some critical vulnerability can be found maybe substantially later in some adapter that was used by AssetManager and was removed long time ago. Its allowances remain and can be exploited to extract any funds held in the tokens from the list that was actual back then.
Impact
A malicious token or adapter can steal all the approved token's balances of the AssetManager. Some assets are routinely residing on the AssetManager's balance: as an example, when the funds, being deposited, can't be placed to the markets right away, they are left on the contract balance until next admin's rebalance() call.
An attacker can setup a bot that tracks this balance and exploit some vulnerability in an already removed adapter to fully drain the balance. Setting the severity to be medium due to the preconditions described.
Code Snippet
removeAdapter() leaves all the infinite approvals:
/** * @dev Remove a ERC20 token to support in AssetManager * @param tokenAddress ERC20 token address */function removeToken(addresstokenAddress) externaloverride onlyAdmin {
bool isExist =false;
uint256 index;
uint256 supportedTokensLength = supportedTokensList.length;
for (uint256 i =0; i < supportedTokensLength; i++) {
if (tokenAddress ==address(supportedTokensList[i])) {
isExist =true;
index = i;
break;
}
}
if (isExist) {
supportedTokensList[index] = supportedTokensList[supportedTokensLength -1];
supportedTokensList.pop();
supportedMarkets[tokenAddress] =false;
+removeTokenApprovals(tokenAddress);
}
}
There new removeTokenApprovals() function similarly to approveAllMarketsMax() cycles across all available markets, setting IERC20Upgradeable(tokenAddress).safeApprove(address(moneyMarkets[i]), 0).
The text was updated successfully, but these errors were encountered:
hyh
medium
Maximal approvals remain for the AssetManager's adapters and tokens after removal
Summary
While adding an adapter and a token to the AssetManager the system provides for the unlimited approvals for the current list of tokens and markets correspondingly, while the removal of the adapter and the token does not clear these approvals, which can be exploited thereafter as the contract balance does hold intermediary funds.
Vulnerability Detail
If the adapter or the token are being removed due to it being found to be malicious or contain a critical issue, treating downstream systems, currently there is no way to remove the exposure to it. This allowance can be exploited to drain AssetManager's balance.
That's a long term threat as market adapter or token being removed keep unlimited allowances forever as there is no mechanics to remove or limit those. I.e. some critical vulnerability can be found maybe substantially later in some adapter that was used by AssetManager and was removed long time ago. Its allowances remain and can be exploited to extract any funds held in the tokens from the list that was actual back then.
Impact
A malicious token or adapter can steal all the approved token's balances of the AssetManager. Some assets are routinely residing on the AssetManager's balance: as an example, when the funds, being deposited, can't be placed to the markets right away, they are left on the contract balance until next admin's rebalance() call.
An attacker can setup a bot that tracks this balance and exploit some vulnerability in an already removed adapter to fully drain the balance. Setting the severity to be medium due to the preconditions described.
Code Snippet
removeAdapter() leaves all the infinite approvals:
https://github.com/sherlock-audit/2022-10-union-finance/blob/main/union-v2-contracts/contracts/asset/AssetManager.sol#L436-L457
Similarly, removeToken() leaves all markets' unlimited approvals with the token intact:
https://github.com/sherlock-audit/2022-10-union-finance/blob/main/union-v2-contracts/contracts/asset/AssetManager.sol#L392-L414
AssetManager's balance aren't necessary empty as some funds are left until manual placement:
https://github.com/sherlock-audit/2022-10-union-finance/blob/main/union-v2-contracts/contracts/asset/AssetManager.sol#L261-L316
Tool used
Manual Review
Recommendation
Consider introducing approvals clearing function and run it on adapter removal, for example:
https://github.com/sherlock-audit/2022-10-union-finance/blob/main/union-v2-contracts/contracts/asset/AssetManager.sol#L436-L457
The same can be done for token removal, for example:
https://github.com/sherlock-audit/2022-10-union-finance/blob/main/union-v2-contracts/contracts/asset/AssetManager.sol#L392-L414
There new removeTokenApprovals() function similarly to approveAllMarketsMax() cycles across all available markets, setting
IERC20Upgradeable(tokenAddress).safeApprove(address(moneyMarkets[i]), 0)
.The text was updated successfully, but these errors were encountered: