Gorples IDO + Core - Entangle Labs

The current implementation of the initialize instruction in the gorples-ido and gorples-core programs does not enforce any constraints to ensure that it is signed by a trusted and known address, such as the program's upgrade authority.

This lack of validation could allow an attacker to front-run the initialization process, potentially setting up the programs with accounts under their control.

- gorples-ido/src/instructions/initialize.rs

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(mut, signer)]
    pub admin: Signer<'info>,

    #[account(init, space = TgeConfig::LEN, payer = admin, seeds = [ROOT, b"CONFIG"], bump)]
    pub tge_config: Box<Account<'info, TgeConfig>>,

// ...

}

pub fn handle_initialize(
    ctx: Context<Initialize>,
    lp_wallet: Pubkey,
    lp_amount: u64,
) -> Result<()> {
    ctx.accounts.tge_config.admin = ctx.accounts.admin.key();
    ctx.accounts.tge_config.lp_wallet = lp_wallet;
    ctx.accounts.tge_config.lp_amount = lp_amount;
    ctx.accounts.tge_config.tge_time = 0;
    // Mint tokens for test
    let bump = &[ctx.bumps.authority][..];
    let seed = &[ROOT, b"AUTHORITY", bump][..];
    let seeds = &[seed][..];
    let accounts = MintGorples {
        mint_authority: ctx.accounts.authority.to_account_info(),
        authority: ctx.accounts.core_authority.to_account_info(),
        config: ctx.accounts.core_config.to_account_info(),
        mint: ctx.accounts.mint.to_account_info(),
        vault: ctx.accounts.vault.to_account_info(),
        token_program: ctx.accounts.token_program.to_account_info(),
    };
    let cpi =
        CpiContext::new_with_signer(ctx.accounts.gorples_core.to_account_info(), accounts, seeds);
    mint_gorples(cpi, 100_000_000)
}

Likewise, the current implementation of the initialize instruction in the gorples-core program does not enforce any constraints to ensure that it is also called by a trusted and known address, leading to the same issue as described above.

- gorples-core/src/lib.rs

    pub fn initialize(
        ctx: Context<Initialize>,
        bridge_authority: Pubkey,
        farm_authority: Pubkey,
        tge_authority: Pubkey,
    ) -> Result<()> {
        ctx.accounts.config.admin = ctx.accounts.admin.key();
        ctx.accounts.config.contracts = [bridge_authority, farm_authority, tge_authority];
        ctx.accounts.config.mint = ctx.accounts.mint.key();
        Ok(())
    }

- gorples-core/src/lib.rs

#[derive(Accounts)]
pub struct Initialize<'info> {
    /// Admin wallet
    #[account(signer, mut)]
    pub admin: Signer<'info>,

    /// Gorples token authority
    /// CHECK: not loaded
    #[account(seeds = [ROOT, b"AUTHORITY"], bump)]
    pub authority: UncheckedAccount<'info>,

    /// Gorples mint
    #[account(
        mut,
        mint::authority = authority,
        mint::decimals = GORPLES_DECIMALS,
        mint::token_program = token_program
    )]
    pub mint: Box<InterfaceAccount<'info, Mint>>,

    /// Gorples config
    #[account(init, payer = admin, space = Config::LEN, seeds = [ROOT, b"CONFIG"], bump)]
    pub config: Box<Account<'info, Config>>,

    pub token_program: Program<'info, Token2022>,
    pub system_program: Program<'info, System>,
}

If the initialization instruction is not called by a known and trusted address, the program becomes vulnerable to malicious exploitation. In such a scenario, an attacker can abuse the initialization process by configuring the program using accounts under their control. This unauthorized access to the program's setup can have severe consequences, including:

• Unintended program behavior: The attacker can manipulate the program's logic, leading to unintended or unpredictable outcomes that can negatively impact the system and its users.

• Theft of assets: By configuring the program with their own accounts, the attacker can potentially divert or steal assets that are meant to be managed or distributed by the program.

• Loss of trust: The exploitation of the program can result in a loss of trust among its users and the broader community, which can be detrimental to the program's adoption and long-term success.

  
  

Both the initialization of the gorples-core and gorples-ido programs can be performed by any non-privileged user.

To reproduce this vulnerability, consider calling the initializer instructions on both gorples-ido and gorples-core program and sign the transaction as a low-privileged (non-admin) user.

The transaction will go through, indicating that anyone can call the programs initializers, and therefore write arbitrary data to critical program's state.

PoC Code

- test/Ido_test.ts

  it("Initialize", async () => {
    gorplesCore = await setupCore(0, BigInt(0), user, mint, provider);

    const tgeConfig = await web3.PublicKey.findProgramAddressSync(
      [ROOT, utf8.encode("CONFIG")],
      gorplesIdoProgram.programId
    )[0];

    const vault = await getOrCreateAssociatedTokenAccount(
      provider.connection,
      admin,
      gorplesCore.mint,
      admin.publicKey,
      undefined,
      undefined,
      undefined,
      TOKEN_2022_PROGRAM_ID
    );

    const authority = web3.PublicKey.findProgramAddressSync(
      [ROOT, utf8.encode("AUTHORITY")],
      gorplesIdoProgram.programId
    )[0];

    await gorplesIdoProgram.methods
    .initialize(user.publicKey, new anchor.BN(50000))
    .accounts({
      admin: user.publicKey,
      tgeConfig: tgeConfig,
      authority: authority,
      coreAuthority: gorplesCore.authority,
      coreConfig: gorplesCore.config,
      mint: gorplesCore.mint,
      vault: vault.address,
      gorplesCore: gorplesCoreProgram.programId,
      tokenProgram: TOKEN_2022_PROGRAM_ID,
      systemProgram: SystemProgram.programId,
    })
    .signers([user])
    .rpc();

    console.log(`Initialized Core and IDO programs as ${user.publicKey} - Low-priv user`);

  });

The initialization process will succeed, demonstrating a scenario where low-privileged users (non-admins) can call the initialize instructions and write insecure data to both program states.

To mitigate these risks, it is recommended to ensure that the initialization instruction is called by a trusted and known address, such as the program's upgrade authority, and that proper access controls and validations are in place.

Remediation Plan

SOLVED: The Entangle team solved the issue by allowing initializers to be called only by DEPLOYER. The commit hash containing the remediation is 1df65f7f6f672651bb488e8c811f1674d2b37fb6.

During the initialization of the program, the lp_wallet address can be set without any further checks for the validity of the provided address. This means that the lp_wallet address could be mistakenly initialized to point to an address that is not controlled by the protocol. It is recommended to enforce the use of a trusted multisig address, controlled by the protocol, to ensure the security and integrity of the platform.

- gorples-ido/src/instructions/initialize.rs

pub fn handle_initialize(
    ctx: Context<Initialize>,
    lp_wallet: Pubkey,
    lp_amount: u64,
) -> Result<()> {
    ctx.accounts.tge_config.admin = ctx.accounts.admin.key();
    ctx.accounts.tge_config.lp_wallet = lp_wallet;
    ctx.accounts.tge_config.lp_amount = lp_amount;
    ctx.accounts.tge_config.tge_time = 0;
    // Mint tokens for test
    let bump = &[ctx.bumps.authority][..];
    let seed = &[ROOT, b"AUTHORITY", bump][..];
    let seeds = &[seed][..];
    let accounts = MintGorples {
        mint_authority: ctx.accounts.authority.to_account_info(),
        authority: ctx.accounts.core_authority.to_account_info(),
        config: ctx.accounts.core_config.to_account_info(),
        mint: ctx.accounts.mint.to_account_info(),
        vault: ctx.accounts.vault.to_account_info(),
        token_program: ctx.accounts.token_program.to_account_info(),
    };
    let cpi =
        CpiContext::new_with_signer(ctx.accounts.gorples_core.to_account_info(), accounts, seeds);
    mint_gorples(cpi, 100_000_000)
}

When adding a new round through the add_round instruction, the value for sol_deposited is not enforced to be equal to 0. This could lead to rounds being initialized with the sol_deposited counter in the Round account having non-zero values. This is illogical, as no $SOL deposits could have been made to a round that hasn't started yet. It is recommended to initialize a round with sol_deposited set to 0 to ensure accurate and consistent tracking of deposits.

- gorples-ido/src/instructions/add_round.rs

pub fn handle_add_round(ctx: Context<AddRound>, round_id: Vec<u8>, round: Round) -> Result<()> {
    if round_id == b"public" && !round.overflow {
        return Err(CustomError::NotOverflowRound.into());
    }
    require_gt!(round.total_tokens, 0);
    require_eq!(round.total_claimed, 0);
    require_eq!(round.total_bought, 0);
    require_gte!(10000, round.immediately_available);
    **ctx.accounts.round = round;
    Ok(())
}

These issues have a direct impact on the calculations performed in the withdraw instructions, specifically in the to_refund variable, which considers the value of round.sol_deposited for its attribution. The withdraw instruction subsequently sends the value of to_refund in $SOL to the address of the lp_wallet.

This issue could lead to a situation where the admin cannot call the withdraw instruction, because it will send the deposited $SOL, which is entitled to the protocol, to the wrong address attributed to the lp_wallet. Also, it is important to highlight that there is no mechanism, admin controlled, that would allow changing the lp_wallet address, to mitigate this issue.

To reproduce this issue, make sure to adjust the utility file rounds.ts accordingly, by manipulating the initializing values, as sol_deposited > 0 on the targeted round.

Call the withdraw instruction as an authorized user. The screenshots below demonstrates the clear difference on the authority's balance after the withdraw instruction is called, and the round was initialized with sol_deposited > 0.

- rounds.ts

  {
    id: "public",
    public: true,
    overflow: true,
    startTime: new anchor.BN(Date.parse("09 May 2024 19:30:00 UTC+3") / 1000),
    duration: new anchor.BN(10 * 60),
    price: new anchor.BN(1),
    totalTokens: new anchor.BN(40_000_000).mul(GORPLETS)
    immediatelyAvailable: new anchor.BN(10000),
    solDeposited: new anchor.BN(10_000_000),
    linearUnlockTime: new anchor.BN(0),
    cliff: new anchor.BN(0),
  },

PoC Code

- test/Ido_test.ts

  it("Withdraw - sol_deposited > 0", async() => {
    /// Check authority balance before purchase
    const gorplesIDOAuthorityBalanceBefore = await provider.connection.getBalance(gorplesIdo.authority);
    console.log(`Gorples IDO authority balance before is: ${gorplesIDOAuthorityBalanceBefore}`);

    /// `publicUser` will be used in this case
    const inputAmount = new anchor.BN(LAMPORTS_PER_SOL * 50); /// oversold state is reached - rounds.ts
    const slot = await provider.connection.getSlot();
    const timestamp = await provider.connection.getBlockTime(slot);

    /// admin calls `set_interval` instruction
    await gorplesIdoProgram.methods
      .setInterval(
        Buffer.from(utf8.encode("public")),
        new anchor.BN(timestamp),
        new anchor.BN(timestamp + 500)
      )
      .accounts({
        admin: admin.publicKey,
        tgeConfig: gorplesIdo.tgeConfig,
        round: publicRound,
      })
      .signers([admin])
      .rpc();

      /// public user purchases 3 times
      for (let i = 0; i < 3; i++) {
        await gorplesIdoProgram.methods
        .buy(Buffer.from(utf8.encode("public")), inputAmount)
        .accounts({
          user: publicUser.publicKey,
          authority: gorplesIdo.authority,
          tgeConfig: gorplesIdo.tgeConfig,
          round: publicRound,
          roundBalance: publicRoundBalance,
          whitelist: null,
          clock: SYSVAR_CLOCK_PUBKEY,
          systemProgram: SystemProgram.programId,
        })
        .signers([publicUser])
        .rpc();
      }

      /// Check authority balance after purchase
      const gorplesIDOAuthorityBalanceAfter = await provider.connection.getBalance(gorplesIdo.authority);
      console.log(`Gorples IDO authority balance after is: ${gorplesIDOAuthorityBalanceAfter}`);

      /// needs to start TGE
      await gorplesIdoProgram.methods
      .startTge()
      .accounts({
        admin: admin.publicKey,
        tgeConfig: gorplesIdo.tgeConfig,
        clock: SYSVAR_CLOCK_PUBKEY,
        systemProgram: SystemProgram.programId,
      })
      .signers([admin])
      .rpc();

      /// admin calls withdraw, as overselling state
      /// is reached, `to_refund` is going to be calculated
      /// and it is expected to withdraw more than warranted 
      /// because of manipulated state when initializing the round 
      /// (sol_deposited > 0)
      await gorplesIdoProgram.methods
      .withdraw()
      .accounts({
        admin: admin.publicKey,
        lpWallet: admin.publicKey,
        tgeConfig: gorplesIdo.tgeConfig,
        round: publicRound,
        authority: gorplesIdo.authority,
        gorplesCoreConfig: gorplesCore.config,
        gorplesCoreAuthority: gorplesCore.authority,
        gorplesMint: gorplesCore.mint,
        gorplesVault: gorplesIdo.vaultAddress,
        tokenProgram: TOKEN_2022_PROGRAM_ID,
        gorplesCore: gorplesCoreProgram.programId,
        associatedTokenProgram: ASSOCIATED_TOKEN_PROGRAM_ID,
        systemProgram: SystemProgram.programId
      })
      .signers([admin])
      .rpc();

    /// Check authority balance after withdraw [admin]
    const gorplesIDOAuthorityBalanceAfterWithdraw = await provider.connection.getBalance(gorplesIdo.authority);
    console.log(`Gorples IDO authority balance AFTER WITHDRAW is: ${gorplesIDOAuthorityBalanceAfterWithdraw}`);
  });

To mitigate this issue, the following measures are recommended:

• Enforce the use of a trusted multisig address for lp_wallet: To ensure the security and integrity of the platform, it is recommended to enforce the use of a trusted multisig address, controlled by the protocol, for the lp_wallet during the initialization of the program. This can be achieved by adding a check to verify the provided lp_wallet address against a pre-determined multisig address.

  
  

• Initialize a round with sol_deposited set to 0: To ensure accurate and consistent tracking of $SOL deposits, it is recommended to initialize a round with the sol_deposited counter in the Round account set to 0. This can be achieved by explicitly setting the value of sol_deposited to 0 during the creation of a new Round.

Remediation Plan

RISK ACCEPTED: The Entangle team accepted the risk related to this finding.

In the gorples-ido and gorples-core programs, the Cargo.toml file has overflow-checks = true enabled, which is a commendable practice. However, it is also recommended to incorporate safe arithmetic operations throughout the program code to further enhance security and reliability.

The provided code excerpts reveal several occurrences of unsafe arithmetic operations.

- gorples-ido/src/instructions/buy.rs

pub fn handle_buy(ctx: Context<Buy>, input_amount: u64) -> Result<()> {
    require_gt!(input_amount, 0, CustomError::ZeroInputAmount);
    require_gt!(ctx.accounts.round.price, 0, CustomError::AirdropOnlyRound);
    let token_amount = 10000 * input_amount / ctx.accounts.round.price;
    require_gt!(token_amount, 0, CustomError::ZeroOutputAmount);
    let cpi_context = CpiContext::new(
        ctx.accounts.system_program.to_account_info(),
        system_program::Transfer {
            from: ctx.accounts.user.to_account_info(),
            to: ctx.accounts.authority.to_account_info(),
        },
    );

- gorples-ido/src/instructions/withdraw.rs

pub fn handle_withdraw(ctx: Context<Withdraw>) -> Result<()> {
    // Transfer sol
    // to_refund = sol * (1 - total/bought)
    let reserved = 1000000;
    let to_refund = if ctx.accounts.round.total_bought > ctx.accounts.round.total_tokens {
        let sol_deposited = u128::from(ctx.accounts.round.sol_deposited);
        sol_deposited
            - sol_deposited * u128::from(ctx.accounts.round.total_tokens)
                / u128::from(ctx.accounts.round.total_bought)
    } else {
        0
    };

- gorples-ido/src/instructions/claim.rs

pub fn handle_claim(ctx: Context<Claim>) -> Result<()> {
    let total_tokens = if ctx.accounts.round.overflow
        && ctx.accounts.round.total_bought > ctx.accounts.round.total_tokens
    {
        u128::from(ctx.accounts.round_balance.total) * u128::from(ctx.accounts.round.total_tokens)
            / u128::from(ctx.accounts.round.total_bought)
    } else {
        u128::from(ctx.accounts.round_balance.total)
    };
    let immediately_available: u128 =
        total_tokens * u128::from(ctx.accounts.round.immediately_available) / 10000;
    let mut total_available = immediately_available;
    let to_vest_total = total_tokens - immediately_available;
    let unlock_time = ctx.accounts.round.linear_unlock_time;
    let delta = ctx.accounts.clock.unix_timestamp as u64 - ctx.accounts.tge_config.tge_time;
    if unlock_time != 0 && to_vest_total != 0 && delta > ctx.accounts.round.cliff {
        let time_delta = u64::min(delta - ctx.accounts.round.cliff, unlock_time);
        total_available += to_vest_total * u128::from(time_delta) / u128::from(unlock_time);
    }
    require_gt!(
        total_available,
        u128::from(ctx.accounts.round_balance.claimed),
        CustomError::ZeroOutputAmount
    );
    let to_claim: u64 = (total_available - u128::from(ctx.accounts.round_balance.claimed))
        .try_into()
        .map_err(|_| CustomError::U64CastOverflow)?;

- gorples-ido/src/instructions/refund.rs

pub fn handle_refund(ctx: Context<Refund>) -> Result<()> {
    if ctx.accounts.round.total_bought <= ctx.accounts.round.total_tokens {
        return Ok(());
    }
    if ctx.accounts.round_balance.refunded {
        return Err(CustomError::AlreadyRefunded.into());
    }
    // solDeposit * (1 - total/bought)
    let sol_deposited = u128::from(ctx.accounts.round_balance.sol_deposited);
    let to_refund = sol_deposited
        - sol_deposited * u128::from(ctx.accounts.round.total_tokens)
            / u128::from(ctx.accounts.round.total_bought);
    require_gt!(to_refund, 0, CustomError::ZeroOutputAmount);
    ctx.accounts.round_balance.refunded = true;
    let bump = &[ctx.bumps.authority][..];
    let seed = &[ROOT, b"AUTHORITY", bump][..];
    let seeds = &[seed][..];
    let cpi_context = CpiContext::new_with_signer(
        ctx.accounts.system_program.to_account_info(),
        system_program::Transfer {
            from: ctx.accounts.authority.to_account_info(),
            to: ctx.accounts.user.to_account_info(),
        },
        seeds,
    );

Utilize Rust's checked_* arithmetic functions on each integer type to strategically detect overflows and underflows within the program. These functions will return a None value if an overflow or underflow occurs, enabling the program to address the issue gracefully and prevent potential security vulnerabilities.

Remediation Plan

RISK ACCEPTED: The Entangle team accepted the risk related to this finding.

In the initialize instruction of the gorples-ido program, there is no enforcement of a reasonable value for the lp_amount parameter. This non-validated lp_amount is then utilized in the withdraw instruction to execute a CPI (Cross-Program Invocation) call to the mint_gorples function, resulting in the minting of lp_amount tokens to the gorples_vault.

Specifically, there is no verification in place for the value provided in the lp_amountparameter, as follows:

- gorples-ido/src/instructions/initialize.rs

pub fn handle_initialize(
    ctx: Context<Initialize>,
    lp_wallet: Pubkey,
    lp_amount: u64,
) -> Result<()> {
    ctx.accounts.tge_config.admin = ctx.accounts.admin.key();
    ctx.accounts.tge_config.lp_wallet = lp_wallet;
    ctx.accounts.tge_config.lp_amount = lp_amount;
    ctx.accounts.tge_config.tge_time = 0;
    // Mint tokens for test
    let bump = &[ctx.bumps.authority][..];
    let seed = &[ROOT, b"AUTHORITY", bump][..];
    let seeds = &[seed][..];
    let accounts = MintGorples {
        mint_authority: ctx.accounts.authority.to_account_info(),
        authority: ctx.accounts.core_authority.to_account_info(),
        config: ctx.accounts.core_config.to_account_info(),
        mint: ctx.accounts.mint.to_account_info(),
        vault: ctx.accounts.vault.to_account_info(),
        token_program: ctx.accounts.token_program.to_account_info(),
    };
    let cpi =
        CpiContext::new_with_signer(ctx.accounts.gorples_core.to_account_info(), accounts, seeds);
    mint_gorples(cpi, 100_000_000)
}

Subsequently, through the withdraw instruction, the lp_amount tokens are transferred to the gorples_vault, which is the associated token account (ATA) for the lp_wallet and gorples_mint.

The absence of a threshold for the lp_amount parameter can lead to the unwarranted or unfair minting of $GORPLES tokens, potentially damaging the fair distribution of LP tokens.

Implement a reasonable threshold value for lp_amount and enforce it by using a require statement during the checks of the initialize function, for example:

    require_gte!(
        <reasonable_lp_amount>,
        lp_amount,
        CustomError::InvalidLpAmount
    );

This will enforce the usage of a valid lp_amount value when initializing the gorples-ido program.

Remediation Plan

RISK ACCEPTED: The Entangle team accepted the risk related to this finding.

The current implementation of the handle_airdrop instruction in the gorples-ido program does not enforce any airdrop thresholds or eligibility criteria, allowing privileged users (admins) to establish any value for the airdrop, which will be later claimable by the user.

- gorples-ido/src/instructions/airdrop.rs

pub fn handle_airdrop(ctx: Context<Airdrop>, amount: u64) -> Result<()> {
    require_gt!(amount, 0, CustomError::ZeroInputAmount);
    ctx.accounts.round.total_bought += amount;
    require_gte!(
        ctx.accounts.round.total_tokens,
        ctx.accounts.round.total_bought,
        CustomError::MaxRoundAmountReached
    );
    ctx.accounts.round_balance.total += amount;
    Ok(())
}

While it effectively prevents to airdrop more than tokens allowed in a determined round, it does not directly ensure the stability of the system because it does not implement thresholds to limit minimum and maximum airdrop amount, per account.

To address this issue, it is recommended to enforce airdrop thresholds by adding checks to the handle_airdrop function that verify the requested airdrop amount against the predefined limits. This can help prevent users from claiming excess tokens and ensure a fair distribution.

Remediation Plan

ACKNOWLEDGED: The Entangle team acknowledged the risk related to this finding.

In the current implementation of the gorples-ido program, the input total_tokens is not validated when initializing a new round using the add_round instruction. This value is only used in the buy instruction when the round is not in an overflow state (!overflow). However, if the round is in an overflow state and total_tokens is set to a disproportionately high amount, it can lead to an unfair distribution of $GORPLES.

- gorples-ido/src/instructions/add_round.rs

pub fn handle_add_round(ctx: Context<AddRound>, round_id: Vec<u8>, round: Round) -> Result<()> {
    if round_id == b"public" && !round.overflow {
        return Err(CustomError::NotOverflowRound.into());
    }
    require_gt!(round.total_tokens, 0);
    require_eq!(round.total_claimed, 0);
    require_eq!(round.total_bought, 0);
    require_gte!(10000, round.immediately_available);
    **ctx.accounts.round = round;
    Ok(())
}

- gorples-ido/src/instructions/claim.rs

pub fn handle_claim(ctx: Context<Claim>) -> Result<()> {
    let total_tokens = if ctx.accounts.round.overflow
        && ctx.accounts.round.total_bought > ctx.accounts.round.total_tokens
    {
        u128::from(ctx.accounts.round_balance.total) * u128::from(ctx.accounts.round.total_tokens)
            / u128::from(ctx.accounts.round.total_bought)
    } else {
        u128::from(ctx.accounts.round_balance.total)
    };
    let immediately_available: u128 =
        total_tokens * u128::from(ctx.accounts.round.immediately_available) / 10000;
    let mut total_available = immediately_available;
    let to_vest_total = total_tokens - immediately_available;
    let unlock_time = ctx.accounts.round.linear_unlock_time;
    let delta = ctx.accounts.clock.unix_timestamp as u64 - ctx.accounts.tge_config.tge_time;
    if unlock_time != 0 && to_vest_total != 0 && delta > ctx.accounts.round.cliff {
        let time_delta = u64::min(delta - ctx.accounts.round.cliff, unlock_time);
        total_available += to_vest_total * u128::from(time_delta) / u128::from(unlock_time);
    }
    require_gt!(
        total_available,
        u128::from(ctx.accounts.round_balance.claimed),
        CustomError::ZeroOutputAmount
    );
    let to_claim: u64 = (total_available - u128::from(ctx.accounts.round_balance.claimed))
        .try_into()
        .map_err(|_| CustomError::U64CastOverflow)?;
    ctx.accounts.round_balance.claimed += to_claim;
    ctx.accounts.round.total_claimed += to_claim;
    let accounts = MintGorples {
        mint_authority: ctx.accounts.authority.to_account_info(),
        authority: ctx.accounts.core_authority.to_account_info(),
        config: ctx.accounts.core_config.to_account_info(),
        mint: ctx.accounts.mint.to_account_info(),
        vault: ctx.accounts.user_vault.to_account_info(),
        token_program: ctx.accounts.token_program.to_account_info(),
    };
    let bump = &[ctx.bumps.authority][..];
    let seed = &[ROOT, b"AUTHORITY", bump][..];
    let seeds = &[seed][..];
    let cpi =
        CpiContext::new_with_signer(ctx.accounts.gorples_core.to_account_info(), accounts, seeds);
    gorples_core::cpi::mint_gorples(cpi, to_claim)
}

In this scenario, anyone can claim a much larger amount of $GORPLES tokens than they should when calling the claim instruction. This issue can have significant consequences, as it undermines the integrity and fairness of the token distribution process, potentially leading to loss of trust among users and stakeholders.

To reproduce this vulnerability, a Round with an abnormally high amount for total_tokens must be initialized. Then, run the following test scripts and expect the user claiming more $GORPLES tokens than expected in a normal situation.

PoC Code

  it("Claim public", async () => {
    const balancePublicUserBeforeClaim = await provider.connection.getBalance(
      publicUser.publicKey
    );
    console.log(`Public user balance before claim is ${balancePublicUserBeforeClaim}`);

    let userVault = await getOrCreateAssociatedTokenAccount(
      provider.connection,
      publicUser,
      gorplesCore.mint,
      publicUser.publicKey,
      undefined,
      undefined,
      undefined,
      TOKEN_2022_PROGRAM_ID
    );

    console.log(`Public user VAULT before claim is ${userVault.amount}`);
    
    expect(userVault.amount).eq(BigInt(0));

    await gorplesIdoProgram.methods
      .claim(Buffer.from(utf8.encode("public")))
      .accounts({
        user: publicUser.publicKey,
        tgeConfig: gorplesIdo.tgeConfig,
        round: publicRound,
        roundBalance: publicRoundBalance,
        mint: gorplesCore.mint,
        userVault: userVault.address,
        authority: gorplesIdo.authority,
        coreAuthority: gorplesCore.authority,
        coreConfig: gorplesCore.config,
        clock: SYSVAR_CLOCK_PUBKEY,
        gorplesCore: gorplesCoreProgram.programId,
        tokenProgram: TOKEN_2022_PROGRAM_ID,
        systemProgram: SystemProgram.programId,
      })
      .signers([publicUser])
      .rpc();
    userVault = await getOrCreateAssociatedTokenAccount(
      provider.connection,
      publicUser,
      gorplesCore.mint,
      publicUser.publicKey,
      undefined,
      undefined,
      undefined,
      TOKEN_2022_PROGRAM_ID
    );

    const balancePublicUserAfterClaim = await provider.connection.getBalance(
      publicUser.publicKey
    );
    console.log(`Public user balance ($SOL) after claim is ${balancePublicUserAfterClaim}`);
    
    
    let userVaultAfter = await getOrCreateAssociatedTokenAccount(
      provider.connection,
      publicUser,
      gorplesCore.mint,
      publicUser.publicKey,
      undefined,
      undefined,
      undefined,
      TOKEN_2022_PROGRAM_ID
    );
    console.log(`Public user VAULT after claim is ${userVaultAfter.amount}`);

  });

• Normal scenario logs (initialized with a normal value for total_tokens )

Public user balance before purchase is 200000000000
Public user balance after purchase is 149998879440
Public user balance before claim is 149998879440
Public user VAULT before claim is 0
Public user balance ($SOL) after claim is 149996721840
Public user VAULT after claim is 4000000000000

• Bad scenario logs (initialized with inflated value for total_tokens)

Public user balance before purchase is 200000000000
Public user balance after purchase is 149998879440
Public user balance before claim is 149998879440
Public user VAULT before claim is 0
Public user balance ($SOL) after claim is 149996721840
Public user VAULT after claim is 500000000000000

Public user VAULT difference is 496000000000000 lamports or 496.000 $GORPLES tokens, when a round is initialized with an unreasonable amount of total_tokens.

To mitigate this risk, it is essential to implement proper input validation for the total_tokens parameter in the add_round instruction. This can be achieved by adding a require statement that checks the value against a predetermined threshold or by using a more dynamic approach that considers other factors, such as the total number of participants or the overall $SOL raised.

Remediation Plan

ACKNOWLEDGED: The Entangle team acknowledged the risk related to this finding.