The `ld2sd_rate` (local-to-shared decimal rate) can be manipulated by an attacker leveraging the `MintCloseAuthority` extension in the Solana program. This manipulation arises because the initializer has control over the mint’s decimal value, which can be altered after the mint’s creation. Such changes lead to crusial discrepancies in token accounting and open pathways for financial exploits. Process of exploiting this vulnerability involves: 1. An attacker creating a mint with a high decimal value (e.g., 18) using the `MintCloseAuthority` extension, assigning the close authority to an address they control. 2. Using this mint during the `InitOFT` process, resulting in a high `ld2sd_rate` (e.g., 1e12 for 6 shared decimals). 3. Closing the mint account with the close authority while the supply remains zero. 4. Reinitializing the mint at the same address with a reduced decimal value (e.g., 6). This manipulation causes the `ld2sd_rate` to become inflated, as the program will continue treating the mint as though it has the original high decimal value, despite its current configuration. This discrepancy results in erroneous token calculations and facilitates financial exploits, such as: **1. Legitimate Transfers Treated as Dust**: Assume a token with a value of $1, where 1 token equals 1e6 units (a decimal value of 6). An attacker sends 100,000 tokens (valued at $1,000,000) using the manipulated `ld2sd_rate`. With an inflated rate of 1e12, the program interprets the amount as 1e11 (100 billion units), which falls below the threshold defined in `remove_dust`. Consequently, the tokens are flagged as dust and are not transferred as intended. **2. Cross-Chain Manipulation**: The attacker initializes another `OFTStore` with a different token escrow account, leveraging the manipulated `ld2sd_rate` to transfer tokens from another chain (e.g., Ethereum) to Solana. Due to the inflated rate on Solana, the received token amount is much higher than intended. The attacker then switches the peer to the correct `OFTStore` with a lower rate, transferring the tokens back to the original chain. This discrepancy between rates allows the attacker to gain an arbitrage-like financial advantage. The current implementation does not validate or disable the `MintCloseAuthority` extension, leaving the program vulnerable to such exploits. ```rust use crate::*; use anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface}; use oapp::endpoint::{instructions::RegisterOAppParams, ID as ENDPOINT_ID}; #[derive(Accounts)] pub struct InitOFT<'info> { #[account(mut)] pub payer: Signer<'info>, #[account( init, payer = payer, space = 8 + OFTStore::INIT_SPACE, seeds = [OFT_SEED, token_escrow.key().as_ref()], bump )] pub oft_store: Account<'info, OFTStore>, #[account( init, payer = payer, space = 8 + LzReceiveTypesAccounts::INIT_SPACE, seeds = [LZ_RECEIVE_TYPES_SEED, oft_store.key().as_ref()], bump )] pub lz_receive_types_accounts: Account<'info, LzReceiveTypesAccounts>, #[account(mint::token_program = token_program)] pub token_mint: InterfaceAccount<'info, Mint>, #[account( init, payer = payer, token::authority = oft_store, token::mint = token_mint, token::token_program = token_program, )] pub token_escrow: InterfaceAccount<'info, TokenAccount>, pub token_program: Interface<'info, TokenInterface>, pub system_program: Program<'info, System>, } impl InitOFT<'_> { pub fn apply(ctx: &mut Context, params: &InitOFTParams) -> Result<()> { // Initialize the oft_store ctx.accounts.oft_store.oft_type = params.oft_type.clone(); require!( ctx.accounts.token_mint.decimals >= params.shared_decimals, OFTError::InvalidDecimals ); ```

Deepthought

Audit