Type Cosplay
Summary
-
Use discriminators to distinguish between different account types
-
To implement a discriminator in Rust, include 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,
} -
To implement a discriminator check in Rust, verify that the discriminator of 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
Discriminatortrait which creates an 8 byte unique identifier for a type -
Use Anchor’s
Account<'info, T>type to automatically check the discriminator of the account when deserializing the account data
Lesson
“Type cosplay” refers to an unexpected account type being used in place of an expected account type. Under the hood, account data is simply stored as an array of bytes that a program deserializes into a custom account type. Without implementing a way to explicitly distinguish between account types, account data from an unexpected account could result in an instruction 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 instruction deserializes the
admin_config account as an AdminConfig type and then performs a owner check
and data validation check.
However, the AdminConfig and UserConfig account types have the same data
structure. This means a UserConfig account type could be passed in as the
admin_config account. As long as the public key stored on the account data
matches the admin signing the transaction, the admin_instruction instruction
would continue to 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::*;
use borsh::{BorshDeserialize, BorshSerialize};
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> {
admin_config: UncheckedAccount<'info>,
admin: Signer<'info>,
}
#[derive(BorshSerialize, BorshDeserialize)]
pub struct AdminConfig {
admin: Pubkey,
}
#[derive(BorshSerialize, BorshDeserialize)]
pub struct UserConfig {
user: Pubkey,
}
Add account discriminator
To solve this, you can add a discriminant field for each account type and set the discriminant when initializing an account.
The example below updates the AdminConfig and UserConfig account types with
a discriminant field. The admin_instruction instruction 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, then
the transaction will fail. Simply make sure to set the appropriate value for
discriminant when you initialize each account (not shown in the example), and
then you can include these discriminant checks in every subsequent instruction.
use anchor_lang::prelude::*;
use borsh::{BorshDeserialize, BorshSerialize};
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> {
admin_config: UncheckedAccount<'info>,
admin: Signer<'info>,
}
#[derive(BorshSerialize, BorshDeserialize)]
pub struct AdminConfig {
discriminant: AccountDiscriminant,
admin: Pubkey,
}
#[derive(BorshSerialize, BorshDeserialize)]
pub struct UserConfig {
discriminant: AccountDiscriminant,
user: Pubkey,
}
#[derive(BorshSerialize, BorshDeserialize, PartialEq)]
pub enum AccountDiscriminant {
Admin,
User,
}
Use Anchor’s Account wrapper
Implementing these checks for every account needed for 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 it to be. 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 on the account matches the expected
account type and throw and error if it does not match.
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 field on the account you are
validating.
use anchor_lang::prelude::*;
use borsh::{BorshDeserialize, BorshSerialize};
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]
pub struct AdminConfig {
admin: Pubkey,
}
#[account]
pub struct UserConfig {
user: Pubkey,
}
It’s important to note that this is a vulnerability you don’t really have to worry about when using Anchor - that’s the whole point of it in the first place! After going through how this can be exploited if not handled properly in a native rust program, hopefully you have a much better understanding of what the purpose of the account discriminator is in an Anchor account. The fact that Anchor sets and checks this discriminator automatically means that developers can spend more time focusing on their product, but it’s still very important to understand what Anchor is doing behind the scenes to develop robust Solana programs.
Lab
For this lab we’ll create two programs to demonstrate a type cosplay vulnerability.
- The first program will initialize program accounts without a discriminator
- The second program will initialize program accounts using Anchor’s
initconstraint 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 programinitialize_user- intializes a standard user accountupdate_admin- allows the existing admin to update the admin authority of the program
Take a look at these three 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
However, both accounts have the same fields and field types:
#[derive(BorshSerialize, BorshDeserialize)]
pub struct AdminConfig {
admin: Pubkey,
}
#[derive(BorshSerialize, BorshDeserialize)]
pub struct User {
user: Pubkey,
}
Because of this, it's possible to pass in a User account in place of the
admin account in the update_admin instruction, thereby bypassing the
requirement that one be an admin to call this instruction.
Take a look at the solana-type-cosplay.ts file in the tests directory. It
contains some basic setup and two tests. One test initializes a user account,
and the other invokes update_admin and passes in the user account in place of
an admin account.
Run anchor test to see that invoking update_admin will complete
successfully.
type-cosplay
✔ Initialize User Account (233ms)
✔ Invoke update admin instruction with user account (487ms)
3. Create type-checked program
Now we'll 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
and you should see the program ID for the new program. Add it to the lib.rs
file of the type-checked program and to the type_checked program in the
Anchor.toml file.
Next, update the test file's setup to include the new program and two new keypairs for the accounts we'll be initializing for the new program.
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. When using the
init constraint to initialize new program accounts, Anchor will automatically
set the first 8 bytes of account data as a unique discriminator for the account
type.
We’ll also add an update_admin instruction that validates the admin_config
account as a AdminConfig account type using Anchor’s Account wrapper. For
any account passed in as the admin_config account, Anchor will automatically
check that the account discriminator matches the expected account type.
use anchor_lang::prelude::*;
declare_id!("FZLRa6vX64QL6Vj2JkqY1Uzyzjgi2PYjCABcDabMo8U7");
#[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 = 8 + 32
)]
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 = 8 + 32
)]
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]
pub struct AdminConfig {
admin: Pubkey,
}
#[account]
pub struct User {
user: Pubkey,
}
5. Test secure update_admin instruction
In the test file, we’ll initialize an AdminConfig account and a User account
from the type_checked program. Then we’ll invoke the updateAdmin instruction
twice passing in the newly created accounts.
describe("type-cosplay", () => {
...
it("Initialize type checked AdminConfig Account", async () => {
await programChecked.methods
.initializeAdmin()
.accounts({
adminConfig: adminAccountType.publicKey,
})
.signers([adminAccountType])
.rpc()
})
it("Initialize type checked User Account", async () => {
await programChecked.methods
.initializeUser()
.accounts({
userAccount: userAccountType.publicKey,
user: provider.wallet.publicKey,
})
.signers([userAccountType])
.rpc()
})
it("Invoke update instruction using User Account", async () => {
try {
await programChecked.methods
.updateAdmin()
.accounts({
adminConfig: userAccountType.publicKey,
newAdmin: newAdmin.publicKey,
admin: provider.wallet.publicKey,
})
.rpc()
} catch (err) {
expect(err)
console.log(err)
}
})
it("Invoke update instruction using AdminConfig Account", async () => {
await programChecked.methods
.updateAdmin()
.accounts({
adminConfig: adminAccountType.publicKey,
newAdmin: newAdmin.publicKey,
admin: provider.wallet.publicKey,
})
.rpc()
})
})
Run anchor test. For the transaction where we pass in the User account type,
we expect the instruction and return an Anchor Error for the account not being
of type AdminConfig.
'Program EU66XDppFCf2Bg7QQr59nyykj9ejWaoW93TSkk1ufXh3 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 EU66XDppFCf2Bg7QQr59nyykj9ejWaoW93TSkk1ufXh3 consumed 4765 of 200000 compute units',
'Program EU66XDppFCf2Bg7QQr59nyykj9ejWaoW93TSkk1ufXh3 failed: custom program error: 0xbba'
Following Anchor best practices and using Anchor types will ensure 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.
If you want to take a look at the final solution code you can find it on the
solution branch of
the repository.
Challenge
Just as with other lessons in this unit, your opportunity to practice avoiding this security exploit lies in auditing your own or other programs.
Take some time to review at least one program and ensure that account types have a discriminator and that those 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, be sure to patch it right away.