Type Cosplay

Summary

Discriminators are 8-byte identifiers written to accounts that distinguish between different account types, ensuring programs interact with the correct data.
Implement a discriminator in Rust by including a field in the account struct to represent the account type.
#[derive(BorshSerialize, BorshDeserialize)] pub struct User { discriminant: AccountDiscriminant, user: Pubkey, } #[derive(BorshSerialize, BorshDeserialize, PartialEq)] pub enum AccountDiscriminant { User, Admin, }
Check the discriminator in Rust to verify that the deserialized account data matches the expected value.
if user.discriminant != AccountDiscriminant::User { return Err(ProgramError::InvalidAccountData.into()); }
In Anchor, program account types automatically implement the Discriminator trait, which creates an 8-byte unique identifier for a type.
Use Anchor's Account<'info, T> type to automatically check the discriminator when deserializing the account data.

"Type cosplay" refers to using an unexpected account type in place of an expected one. Under the hood, account data is stored as an array of bytes that a program deserializes into a custom account type. Without a method to distinguish between account types explicitly, data from an unexpected account could result in instructions being used in unintended ways.

Unchecked Account

In the example below, both the AdminConfig and UserConfig account types store a single public key. The admin_instruction deserializes the admin_config account as an AdminConfig type and then performs an owner check and data validation check.

However, since the AdminConfig and UserConfig account types have the same data structure, a UserConfig account type could be passed as the admin_config account. As long as the public key stored on the account matches the admin signing the transaction, the admin_instruction would process, even if the signer isn't actually an admin.

Note that the names of the fields stored on the account types (admin and user) make no difference when deserializing account data. The data is serialized and deserialized based on the order of fields rather than their names.

use anchor_lang::prelude::*;
 
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
 
#[program]
pub mod type_cosplay_insecure {
    use super::*;
 
    pub fn admin_instruction(ctx: Context<AdminInstruction>) -> Result<()> {
        let account_data =
            AdminConfig::try_from_slice(&ctx.accounts.admin_config.data.borrow()).unwrap();
        if ctx.accounts.admin_config.owner != ctx.program_id {
            return Err(ProgramError::IllegalOwner.into());
        }
        if account_data.admin != ctx.accounts.admin.key() {
            return Err(ProgramError::InvalidAccountData.into());
        }
        msg!("Admin {}", account_data.admin);
        Ok(())
    }
}
 
#[derive(Accounts)]
pub struct AdminInstruction<'info> {
    /// CHECK: This account is not being validated by Anchor
    admin_config: UncheckedAccount<'info>,
    admin: Signer<'info>,
}
 
#[derive(AnchorSerialize, AnchorDeserialize, InitSpace)]
pub struct AdminConfig {
    admin: Pubkey,
}
 
#[derive(AnchorSerialize, AnchorDeserialize, InitSpace)]
pub struct UserConfig {
    user: Pubkey,
}

Add Account Discriminator

To resolve this, add a discriminant field for each account type and set the discriminant when initializing an account.

Info

While they sound similar, a Rust discriminant isn't the same thing as an Anchor discriminator!

Rust discriminant: This is an internal value that Rust uses to keep track of which variant an enum currently represents. It's like a behind-the-scenes label for enum variants.
Anchor discriminator: This is a unique 8-byte identifier that Anchor adds to the beginning of each account's data. It helps Solana programs quickly recognize what type of account they're dealing with.

In simple terms:

Discriminants are Rust's way of organizing enum variants.
Discriminators are Anchor's way of labeling different account types in Solana.

The example below updates the AdminConfig and UserConfig account types with a discriminant field. The admin_instruction now includes an additional data validation check for the discriminant field.

if account_data.discriminant != AccountDiscriminant::Admin {
    return Err(ProgramError::InvalidAccountData.into());
}

If the discriminant field of the account passed into the instruction as the admin_config account does not match the expected AccountDiscriminant, the transaction will fail. Ensure that the appropriate value for discriminant is set when initializing each account, and then include these checks in every subsequent instruction.

use anchor_lang::prelude::*;
 
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
 
#[program]
pub mod type_cosplay_secure {
    use super::*;
 
    pub fn admin_instruction(ctx: Context<AdminInstruction>) -> Result<()> {
        let account_data =
            AdminConfig::try_from_slice(&ctx.accounts.admin_config.data.borrow()).unwrap();
        if ctx.accounts.admin_config.owner != ctx.program_id {
            return Err(ProgramError::IllegalOwner.into());
        }
        if account_data.admin != ctx.accounts.admin.key() {
            return Err(ProgramError::InvalidAccountData.into());
        }
        if account_data.discriminant != AccountDiscriminant::Admin {
            return Err(ProgramError::InvalidAccountData.into());
        }
        msg!("Admin {}", account_data.admin);
        Ok(())
    }
}
 
#[derive(Accounts)]
pub struct AdminInstruction<'info> {
    /// CHECK: This account is not being validated by Anchor
    admin_config: UncheckedAccount<'info>,
    admin: Signer<'info>,
}
 
#[derive(AnchorSerialize, AnchorDeserialize, InitSpace)]
pub struct AdminConfig {
    discriminant: AccountDiscriminant,
    admin: Pubkey,
}
 
#[derive(AnchorSerialize, AnchorDeserialize, InitSpace)]
pub struct UserConfig {
    discriminant: AccountDiscriminant,
    user: Pubkey,
}
 
#[derive(AnchorSerialize, AnchorDeserialize, PartialEq, InitSpace)]
pub enum AccountDiscriminant {
    Admin,
    User,
}

Use Anchor's Account Wrapper

Implementing these checks for every account in every instruction can be tedious. Fortunately, Anchor provides a #[account] attribute macro for automatically implementing traits that every account should have.

Structs marked with #[account] can then be used with Account to validate that the passed-in account is indeed the type you expect. When initializing an account whose struct representation has the #[account] attribute, the first 8 bytes are automatically reserved for a discriminator unique to the account type. When deserializing the account data, Anchor will automatically check if the discriminator matches the expected account type and throw an error if it does not.

In the example below, Account<'info, AdminConfig> specifies that the admin_config account should be of type AdminConfig. Anchor then automatically checks that the first 8 bytes of account data match the discriminator of the AdminConfig type.

The data validation check for the admin field is also moved from the instruction logic to the account validation struct using the has_one constraint. #[account(has_one = admin)] specifies that the admin_config account's admin field must match the admin account passed into the instruction. Note that for the has_one constraint to work, the naming of the account in the struct must match the naming of the field on the account you are validating.

use anchor_lang::prelude::*;
 
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
 
#[program]
pub mod type_cosplay_recommended {
    use super::*;
 
    pub fn admin_instruction(ctx: Context<AdminInstruction>) -> Result<()> {
        msg!("Admin {}", ctx.accounts.admin_config.admin);
        Ok(())
    }
}
 
#[derive(Accounts)]
pub struct AdminInstruction<'info> {
    #[account(has_one = admin)]
    admin_config: Account<'info, AdminConfig>,
    admin: Signer<'info>,
}
 
#[account]
#[derive(InitSpace)]
pub struct AdminConfig {
    admin: Pubkey,
}
 
#[account]
#[derive(InitSpace)]
pub struct UserConfig {
    user: Pubkey,
}

This vulnerability is something you generally don't have to worry about when using Anchor—that's the whole point! However, after exploring how this issue can arise in native Rust programs, you should now have a better understanding of the importance of the account discriminator in an Anchor account. Anchor's automatic discriminator checks mean that developers can focus more on their product, but it's still crucial to understand what Anchor is doing behind the scenes to build robust Solana programs.

Lab

In this lab, you'll create two programs to demonstrate a type cosplay vulnerability:

The first program initializes accounts without a discriminator.
The second program initializes accounts using Anchor's init constraint, which automatically sets an account discriminator.

1. Starter

To get started, download the starter code from the starter branch of this repository. The starter code includes a program with three instructions and some tests.

The three instructions are:

initialize_admin- Initializes an admin account and sets the admin authority of the program.
initialize_user - Initializes a standard user account.
update_admin - Allows the existing admin to update the admin authority of the program.

Review the instructions in the lib.rs file. The last instruction should only be callable by the account matching the admin field on the admin account initialized using the initialize_admin instruction.

2. Test Insecure update_admin Instruction

Both the AdminConfig and User account types have the same fields and field types:

#[derive(AnchorSerialize, AnchorDeserialize)]
pub struct AdminConfig {
    admin: Pubkey,
}
 
#[derive(AnchorSerialize, AnchorDeserialize)]
pub struct User {
    user: Pubkey,
}

Because of this, it's possible to pass a User account in place of the admin account in the update_admin instruction, bypassing the requirement that only an admin can call this instruction.

Take a look at the solana-type-cosplay.ts file in the tests directory. It contains a basic setup and two tests: one initializes a user account, and the other invokes update_admin with the user account instead of an admin account.

Run anchor test to see that invoking update_admin completes successfully:

  type-cosplay
    ✔ Initialize User Account (223ms)
    ✔ Invoke update admin instruction with user account (442ms)

3. Create type-checked Program

Next, create a new program called type-checked by running anchor new type-checked from the root of the existing anchor program.

Now, in your programs folder, you will have two programs. Run anchor keys list to see the program ID for the new program. Add it to the lib.rs file of the type-checked program and to the Anchor.toml file.

Update the test file's setup to include the new program and two new keypairs for the accounts to be initialized:

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { TypeCosplay } from "../target/types/type_cosplay";
import { TypeChecked } from "../target/types/type_checked";
import { expect } from "chai";
 
describe("type-cosplay", () => {
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);
 
  const program = anchor.workspace.TypeCosplay as Program<TypeCosplay>;
  const programChecked = anchor.workspace.TypeChecked as Program<TypeChecked>;
 
  const userAccount = anchor.web3.Keypair.generate();
  const newAdmin = anchor.web3.Keypair.generate();
 
  const userAccountChecked = anchor.web3.Keypair.generate();
  const adminAccountChecked = anchor.web3.Keypair.generate();
});

4. Implement the type-checked Program

In the type_checked program, add two instructions using the init constraint to initialize an AdminConfig account and a User account. Anchor will automatically set the first 8 bytes of account data as a unique discriminator for the account type.

Add an update_admin instruction that validates the admin_config account as an AdminConfig account type using Anchor's Account wrapper. Anchor will automatically check that the account discriminator matches the expected account type:

use anchor_lang::prelude::*;
 
declare_id!("G36iNpB591wxFeaeq55qgTwHKJspBrETmgok94oyqgcc");
 
const DISCRIMINATOR_SIZE: usize = 8;
 
#[program]
pub mod type_checked {
    use super::*;
 
    pub fn initialize_admin(ctx: Context<InitializeAdmin>) -> Result<()> {
        ctx.accounts.admin_config.admin = ctx.accounts.admin.key();
        Ok(())
    }
 
    pub fn initialize_user(ctx: Context<InitializeUser>) -> Result<()> {
        ctx.accounts.user_account.user = ctx.accounts.user.key();
        Ok(())
    }
 
    pub fn update_admin(ctx: Context<UpdateAdmin>) -> Result<()> {
        ctx.accounts.admin_config.admin = ctx.accounts.admin.key();
        Ok(())
    }
}
 
#[derive(Accounts)]
pub struct InitializeAdmin<'info> {
    #[account(
        init,
        payer = admin,
        space = DISCRIMINATOR_SIZE + AdminConfig::INIT_SPACE
    )]
    pub admin_config: Account<'info, AdminConfig>,
    #[account(mut)]
    pub admin: Signer<'info>,
    pub system_program: Program<'info, System>,
}
 
#[derive(Accounts)]
pub struct InitializeUser<'info> {
    #[account(
        init,
        payer = user,
        space = DISCRIMINATOR_SIZE + User::INIT_SPACE
    )]
    pub user_account: Account<'info, User>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}
 
#[derive(Accounts)]
pub struct UpdateAdmin<'info> {
    #[account(
        mut,
        has_one = admin
    )]
    pub admin_config: Account<'info, AdminConfig>,
    pub new_admin: SystemAccount<'info>,
    #[account(mut)]
    pub admin: Signer<'info>,
}
 
#[account]
#[derive(InitSpace)]
pub struct AdminConfig {
    admin: Pubkey,
}
 
#[account]
#[derive(InitSpace)]
pub struct User {
    user: Pubkey,
}

5. Test Secure update_admin Instruction

In the test file, initialize an AdminConfig account and a User account from the type_checked program. Then, invoke the updateAdmin instruction twice, passing in the newly created accounts:

describe("type-cosplay", () => {
    ...
 
  it("Initialize type checked AdminConfig Account", async () => {
    try {
      await programChecked.methods
        .initializeAdmin()
        .accounts({
          adminConfig: adminAccountChecked.publicKey,
        })
        .signers([adminAccountChecked])
        .rpc();
    } catch (error) {
      throw new Error(
        `Initializing type checked AdminConfig Account failed: ${error.message}`
      );
    }
  });
 
  it("Initialize type checked User Account", async () => {
    try {
      await programChecked.methods
        .initializeUser()
        .accounts({
          userAccount: userAccountChecked.publicKey,
          user: provider.wallet.publicKey,
        })
        .signers([userAccountChecked])
        .rpc();
    } catch (error) {
      throw new Error(
        `Initializing type checked User Account failed: ${error.message}`
      );
    }
  });
 
  it("Invoke update instruction using User Account", async () => {
    try {
      await programChecked.methods
        .updateAdmin()
        .accounts({
          adminConfig: userAccountChecked.publicKey,
          newAdmin: newAdmin.publicKey,
          admin: provider.wallet.publicKey,
        })
        .rpc();
    } catch (error) {
      expect(error);
      console.log(error);
    }
  });
 
  it("Invoke update instruction using AdminConfig Account", async () => {
    try {
      await programChecked.methods
        .updateAdmin()
        .accounts({
          adminConfig: adminAccountChecked.publicKey,
          newAdmin: newAdmin.publicKey,
          admin: provider.wallet.publicKey,
        })
        .rpc();
    } catch (error) {
      throw new Error(
        `Invoking update instruction using AdminConfig Account failed: ${error.message}`
      );
    }
  });
})

Run anchor test. For the transaction where we pass in the User account type, we expect the instruction to return an Anchor Error due to the account not being of type AdminConfig:

'Program G36iNpB591wxFeaeq55qgTwHKJspBrETmgok94oyqgcc invoke [1]',
'Program log: Instruction: UpdateAdmin',
'Program log: AnchorError caused by account: admin_config. Error Code: AccountDiscriminatorMismatch. Error Number: 3002. Error Message: 8 byte discriminator did not match what was expected.',
'Program G36iNpB591wxFeaeq55qgTwHKJspBrETmgok94oyqgcc consumed 3506 of 200000 compute units',
'Program G36iNpB591wxFeaeq55qgTwHKJspBrETmgok94oyqgcc failed: custom program error: 0xbba'

Following Anchor's best practices ensures that your programs avoid this vulnerability. Always use the #[account] attribute when creating account structs, use the init constraint when initializing accounts, and use the Account type in your account validation structs.

For the final solution code, you can find it on the solution branch of the repository.

Challenge

As with other lessons in this unit, practice avoiding this security exploit by auditing your own or other programs.

Review at least one program and ensure that account types have a discriminator and that these are checked for each account and instruction. Since standard Anchor types handle this check automatically, you're more likely to find a vulnerability in a native program.

Remember, if you find a bug or exploit in somebody else's program, please alert them. If you find one in your own program, patch it immediately.

Completed the lab?

Push your code to GitHub and tell us what you thought of this lesson!