Liquidity Management

Details

The initializer in the PerpetualVault contract performs only basic validations, such as non-zero address checks and minimal ERC20 function calls (e.g., decimals()) to validate market tokens.

Root Cause

The vulnerability arises from the reliance on rudimentary checks that:

• Confirm addresses are non-zero and point to a contract.

• Verify minimal ERC20 functionality (via decimals()).

These checks do not ensure full adherence to the ERC20 standard.

Impact

• Owner Compromise Risk:

If the owner’s credentials are compromised or if the owner misconfigures the vault (e.g., by providing a malicious token contract), the vault’s operations could be adversely affected. Potential impacts include:

• Incorrect calculations (e.g., in share allocation or collateral management).

• Unexpected behavior during vault operations, which could lead to financial loss.

Recommendation

1. Enhance Token Verification:

• Implement more robust checks to verify full ERC20 compliance (e.g., using ERC165 or checking for additional function selectors).

2. Strengthen Owner Controls:

• Consider implementing multi-signature authorization or additional governance layers for the initialization process to mitigate risks associated with owner compromise.

3. Implement a Whitelist:

• Introduce a whitelist of trusted token addresses that are allowed to be used, ensuring that even if the owner account is compromised, only approved tokens can be initialized.

4. Improve Logging and Auditing:

• Log detailed initialization parameters and perform periodic audits to ensure that only benign and expected contracts are used.

Proof of Concept

1. Deploy a Malicious Token Contract:

An attacker could deploy a token contract that passes basic checks:

pragma solidity ^0.8.0*;*

contract MaliciousToken {

uint8 public constant decimals = 18;

function totalSupply() external pure returns (uint256) {

return 1000;

}

function balanceOf(address account) external pure returns (uint256) {

return 1000;

}

function transfer(address recipient, uint256 amount) external returns (bool) {

// Hidden malicious logic here...

return true;

}

}

2. Owner Initialization with MaliciousToken:

If the owner (or a compromised owner account) uses the address of MaliciousToken when calling the initializer (via IVaultReader.getMarket(_market) returning marketInfo with shortToken set to MaliciousToken), the initializer’s basic checks would pass:

• The addresses are non-zero.

• The address points to a contract.

• MaliciousToken.decimals() returns 18.

3. Outcome:

Although an external attacker cannot force this initialization due to owner-only access, a compromised owner can inadvertently initialize the vault with a malicious token. This could lead to miscalculations, unauthorized transfers, or other unintended behavior within the vault.

Conclusion

The insufficient interface validation in the PerpetualVault initializer remains a potential risk; however, the fact that only the owner can perform the initialization significantly reduces its exploitability by external parties. Nonetheless, it is recommended to improve token verification and introduce additional governance measures to mitigate risks in the event of owner compromise.