PDA Sharing
Summary
- Using the same PDA for multiple authority domains opens your program up to the possibility of users accessing data and funds that don't belong to them
- Prevent the same PDA from being used for multiple accounts by using seeds that are user and/or domain-specific
- Use Anchor’s
seedsandbumpconstraints to validate that a PDA is derived using the expected seeds and bump
Lesson
PDA sharing refers to using the same PDA as a signer across multiple users or domains. Especially when using PDAs for signing, it may seem appropriate to use a global PDA to represent the program. However, this opens up the possibility of account validation passing but a user being able to access funds, transfers, or data not belonging to them.
Insecure global PDA
In the example below, the authority of the vault account is a PDA derived
using the mint address stored on the pool account. This PDA is passed into
the instruction as the authority account to sign for the transfer tokens from
the vault to the withdraw_destination.
Using the mint address as a seed to derive the PDA to sign for the vault is
insecure because multiple pool accounts could be created for the same vault
token account, but a different withdraw_destination. By using the mint as a
seed derive the PDA to sign for token transfers, any pool account could sign
for the transfer of tokens from a vault token account to an arbitrary
withdraw_destination.
use anchor_lang::prelude::*;
use anchor_spl::token::{self, Token, TokenAccount};
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
#[program]
pub mod pda_sharing_insecure {
use super::*;
pub fn withdraw_tokens(ctx: Context<WithdrawTokens>) -> Result<()> {
let amount = ctx.accounts.vault.amount;
let seeds = &[ctx.accounts.pool.mint.as_ref(), &[ctx.accounts.pool.bump]];
token::transfer(ctx.accounts.transfer_ctx().with_signer(&[seeds]), amount)
}
}
#[derive(Accounts)]
pub struct WithdrawTokens<'info> {
#[account(has_one = vault, has_one = withdraw_destination)]
pool: Account<'info, TokenPool>,
vault: Account<'info, TokenAccount>,
withdraw_destination: Account<'info, TokenAccount>,
authority: AccountInfo<'info>,
token_program: Program<'info, Token>,
}
impl<'info> WithdrawTokens<'info> {
pub fn transfer_ctx(&self) -> CpiContext<'_, '_, '_, 'info, token::Transfer<'info>> {
let program = self.token_program.to_account_info();
let accounts = token::Transfer {
from: self.vault.to_account_info(),
to: self.withdraw_destination.to_account_info(),
authority: self.authority.to_account_info(),
};
CpiContext::new(program, accounts)
}
}
#[account]
pub struct TokenPool {
vault: Pubkey,
mint: Pubkey,
withdraw_destination: Pubkey,
bump: u8,
}
Secure account specific PDA
One approach to create an account specific PDA is to use the
withdraw_destination as a seed to derive the PDA used as the authority of the
vault token account. This ensures the PDA signing for the CPI in the
withdraw_tokens instruction is derived using the intended
withdraw_destination token account. In other words, tokens from a vault
token account can only be withdrawn to the withdraw_destination that was
originally initialized with the pool account.
use anchor_lang::prelude::*;
use anchor_spl::token::{self, Token, TokenAccount};
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
#[program]
pub mod pda_sharing_secure {
use super::*;
pub fn withdraw_tokens(ctx: Context<WithdrawTokens>) -> Result<()> {
let amount = ctx.accounts.vault.amount;
let seeds = &[
ctx.accounts.pool.withdraw_destination.as_ref(),
&[ctx.accounts.pool.bump],
];
token::transfer(ctx.accounts.transfer_ctx().with_signer(&[seeds]), amount)
}
}
#[derive(Accounts)]
pub struct WithdrawTokens<'info> {
#[account(has_one = vault, has_one = withdraw_destination)]
pool: Account<'info, TokenPool>,
vault: Account<'info, TokenAccount>,
withdraw_destination: Account<'info, TokenAccount>,
authority: AccountInfo<'info>,
token_program: Program<'info, Token>,
}
impl<'info> WithdrawTokens<'info> {
pub fn transfer_ctx(&self) -> CpiContext<'_, '_, '_, 'info, token::Transfer<'info>> {
let program = self.token_program.to_account_info();
let accounts = token::Transfer {
from: self.vault.to_account_info(),
to: self.withdraw_destination.to_account_info(),
authority: self.authority.to_account_info(),
};
CpiContext::new(program, accounts)
}
}
#[account]
pub struct TokenPool {
vault: Pubkey,
mint: Pubkey,
withdraw_destination: Pubkey,
bump: u8,
}
Anchor’s seeds and bump constraints
PDAs can be used as both the address of an account and allow programs to sign for the PDAs they own.
The example below uses a PDA derived using the withdraw_destination as both
the address of the pool account and owner of the vault token account. This
means that only the pool account associated with correct vault and
withdraw_destination can be used in the withdraw_tokens instruction.
You can use Anchor’s seeds and bump constraints with the #[account(...)]
attribute to validate the pool account PDA. Anchor derives a PDA using the
seeds and bump specified and compare against the account passed into the
instruction as the pool account. The has_one constraint is used to further
ensure that only the correct accounts stored on the pool account are passed
into the instruction.
use anchor_lang::prelude::*;
use anchor_spl::token::{self, Token, TokenAccount};
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");
#[program]
pub mod pda_sharing_recommended {
use super::*;
pub fn withdraw_tokens(ctx: Context<WithdrawTokens>) -> Result<()> {
let amount = ctx.accounts.vault.amount;
let seeds = &[
ctx.accounts.pool.withdraw_destination.as_ref(),
&[ctx.accounts.pool.bump],
];
token::transfer(ctx.accounts.transfer_ctx().with_signer(&[seeds]), amount)
}
}
#[derive(Accounts)]
pub struct WithdrawTokens<'info> {
#[account(
has_one = vault,
has_one = withdraw_destination,
seeds = [withdraw_destination.key().as_ref()],
bump = pool.bump,
)]
pool: Account<'info, TokenPool>,
vault: Account<'info, TokenAccount>,
withdraw_destination: Account<'info, TokenAccount>,
token_program: Program<'info, Token>,
}
impl<'info> WithdrawTokens<'info> {
pub fn transfer_ctx(&self) -> CpiContext<'_, '_, '_, 'info, token::Transfer<'info>> {
let program = self.token_program.to_account_info();
let accounts = token::Transfer {
from: self.vault.to_account_info(),
to: self.withdraw_destination.to_account_info(),
authority: self.pool.to_account_info(),
};
CpiContext::new(program, accounts)
}
}
#[account]
pub struct TokenPool {
vault: Pubkey,
mint: Pubkey,
withdraw_destination: Pubkey,
bump: u8,
}
Lab
Let’s practice by creating a simple program to demonstrate how a PDA sharing can allow an attacker to withdraw tokens that don’t belong to them. this lab expands on the examples above by including the instructions to initialize the required program accounts.
1. Starter
To get started, download the starter code on the starter branch of
this repository.
The starter code includes a program with two instructions and the boilerplate
setup for the test file.
The initialize_pool instruction initializes a new TokenPool that stores a
vault, mint, withdraw_destination, and bump. The vault is a token
account where the authority is set as a PDA derived using the mint address.
The withdraw_insecure instruction will transfer tokens in the vault token
account to a withdraw_destination token account.
However, as written the seeds used for signing are not specific to the vault's withdraw destination, thus opening up the program to security exploits. Take a minute to familiarize yourself with the code before continuing on.
2. Test withdraw_insecure instruction
The test file includes the code to invoke the initialize_pool instruction and
then mint 100 tokens to the vault token account. It also includes a test to
invoke the withdraw_insecure using the intended withdraw_destination. This
shows that the instructions can be used as intended.
After that, there are two more tests to show how the instructions are vulnerable to exploit.
The first test invokes the initialize_pool instruction to create a "fake"
pool account using the same vault token account, but a different
withdraw_destination.
The second test withdraws from this pool, stealing funds from the vault.
it("Insecure initialize allows pool to be initialized with wrong vault", async () => {
await program.methods
.initializePool(authInsecureBump)
.accounts({
pool: poolInsecureFake.publicKey,
mint: mint,
vault: vaultInsecure.address,
withdrawDestination: withdrawDestinationFake,
payer: walletFake.publicKey,
})
.signers([walletFake, poolInsecureFake])
.rpc();
await new Promise(x => setTimeout(x, 1000));
await spl.mintTo(
connection,
wallet.payer,
mint,
vaultInsecure.address,
wallet.payer,
100,
);
const account = await spl.getAccount(connection, vaultInsecure.address);
expect(Number(account.amount)).to.equal(100);
});
it("Insecure withdraw allows stealing from vault", async () => {
await program.methods
.withdrawInsecure()
.accounts({
pool: poolInsecureFake.publicKey,
vault: vaultInsecure.address,
withdrawDestination: withdrawDestinationFake,
authority: authInsecure,
signer: walletFake.publicKey,
})
.signers([walletFake])
.rpc();
const account = await spl.getAccount(connection, vaultInsecure.address);
expect(Number(account.amount)).to.equal(0);
});
Run anchor test to see that the transactions complete successfully and the
withdraw_instrucure instruction allows the vault token account to be drained
to a fake withdraw destination stored on the fake pool account.
3. Add initialize_pool_secure instruction
Now let's add a new instruction to the program for securely initializing a pool.
This new initialize_pool_secure instruction will initialize a pool account
as a PDA derived using the withdraw_destination. It will also initialize a
vault token account with the authority set as the pool PDA.
pub fn initialize_pool_secure(ctx: Context<InitializePoolSecure>) -> Result<()> {
ctx.accounts.pool.vault = ctx.accounts.vault.key();
ctx.accounts.pool.mint = ctx.accounts.mint.key();
ctx.accounts.pool.withdraw_destination = ctx.accounts.withdraw_destination.key();
ctx.accounts.pool.bump = *ctx.bumps.get("pool").unwrap();
Ok(())
}
...
#[derive(Accounts)]
pub struct InitializePoolSecure<'info> {
#[account(
init,
payer = payer,
space = 8 + 32 + 32 + 32 + 1,
seeds = [withdraw_destination.key().as_ref()],
bump
)]
pub pool: Account<'info, TokenPool>,
pub mint: Account<'info, Mint>,
#[account(
init,
payer = payer,
token::mint = mint,
token::authority = pool,
)]
pub vault: Account<'info, TokenAccount>,
pub withdraw_destination: Account<'info, TokenAccount>,
#[account(mut)]
pub payer: Signer<'info>,
pub system_program: Program<'info, System>,
pub token_program: Program<'info, Token>,
pub rent: Sysvar<'info, Rent>,
}
4. Add withdraw_secure instruction
Next, add a withdraw_secure instruction. This instruction will withdraw tokens
from the vault token account to the withdraw_destination. The pool account
is validated using the seeds and bump constraints to ensure the correct PDA
account is provided. The has_one constraints check that the correct vault
and withdraw_destination token accounts are provided.
pub fn withdraw_secure(ctx: Context<WithdrawTokensSecure>) -> Result<()> {
let amount = ctx.accounts.vault.amount;
let seeds = &[
ctx.accounts.pool.withdraw_destination.as_ref(),
&[ctx.accounts.pool.bump],
];
token::transfer(ctx.accounts.transfer_ctx().with_signer(&[seeds]), amount)
}
...
#[derive(Accounts)]
pub struct WithdrawTokensSecure<'info> {
#[account(
has_one = vault,
has_one = withdraw_destination,
seeds = [withdraw_destination.key().as_ref()],
bump = pool.bump,
)]
pool: Account<'info, TokenPool>,
#[account(mut)]
vault: Account<'info, TokenAccount>,
#[account(mut)]
withdraw_destination: Account<'info, TokenAccount>,
token_program: Program<'info, Token>,
}
impl<'info> WithdrawTokensSecure<'info> {
pub fn transfer_ctx(&self) -> CpiContext<'_, '_, '_, 'info, token::Transfer<'info>> {
let program = self.token_program.to_account_info();
let accounts = token::Transfer {
from: self.vault.to_account_info(),
to: self.withdraw_destination.to_account_info(),
authority: self.pool.to_account_info(),
};
CpiContext::new(program, accounts)
}
}
5. Test withdraw_secure instruction
Finally, return to the test file to test the withdraw_secure instruction and
show that by narrowing the scope of our PDA signing authority, we've removed the
vulnerability.
Before we write a test showing the vulnerability has been patched let's write a test that simply shows that the initialization and withdraw instructions work as expected:
it("Secure pool initialization and withdraw works", async () => {
const withdrawDestinationAccount = await getAccount(
provider.connection,
withdrawDestination,
);
await program.methods
.initializePoolSecure()
.accounts({
pool: authSecure,
mint: mint,
vault: vaultRecommended.publicKey,
withdrawDestination: withdrawDestination,
})
.signers([vaultRecommended])
.rpc();
await new Promise(x => setTimeout(x, 1000));
await spl.mintTo(
connection,
wallet.payer,
mint,
vaultRecommended.publicKey,
wallet.payer,
100,
);
await program.methods
.withdrawSecure()
.accounts({
pool: authSecure,
vault: vaultRecommended.publicKey,
withdrawDestination: withdrawDestination,
})
.rpc();
const afterAccount = await getAccount(
provider.connection,
withdrawDestination,
);
expect(
Number(afterAccount.amount) - Number(withdrawDestinationAccount.amount),
).to.equal(100);
});
Now, we'll test that the exploit no longer works. Since the vault authority is
the pool PDA derived using the intended withdraw_destination token account,
there should no longer be a way to withdraw to an account other than the
intended withdraw_destination.
Add a test that shows you can't call withdraw_secure with the wrong withdrawal
destination. It can use the pool and vault created in the previous test.
it("Secure withdraw doesn't allow withdraw to wrong destination", async () => {
try {
await program.methods
.withdrawSecure()
.accounts({
pool: authSecure,
vault: vaultRecommended.publicKey,
withdrawDestination: withdrawDestinationFake,
})
.signers([walletFake])
.rpc();
assert.fail("expected error");
} catch (error) {
console.log(error.message);
expect(error);
}
});
Lastly, since the pool account is a PDA derived using the
withdraw_destination token account, we can’t create a fake pool account
using the same PDA. Add one more test showing that the new
initialize_pool_secure instruction won't let an attacker put in the wrong
vault.
it("Secure pool initialization doesn't allow wrong vault", async () => {
try {
await program.methods
.initializePoolSecure()
.accounts({
pool: authSecure,
mint: mint,
vault: vaultInsecure.address,
withdrawDestination: withdrawDestination,
})
.signers([vaultRecommended])
.rpc();
assert.fail("expected error");
} catch (error) {
console.log(error.message);
expect(error);
}
});
Run anchor test and to see that the new instructions don't allow an attacker
to withdraw from a vault that isn't theirs.
pda-sharing
✔ Initialize Pool Insecure (981ms)
✔ Withdraw (470ms)
✔ Insecure initialize allows pool to be initialized with wrong vault (10983ms)
✔ Insecure withdraw allows stealing from vault (492ms)
✔ Secure pool initialization and withdraw works (2502ms)
unknown signer: ARjxAsEPj6YsAPKaBfd1AzUHbNPtAeUsqusAmBchQTfV
✔ Secure withdraw doesn't allow withdraw to wrong destination
unknown signer: GJcHJLot3whbY1aC9PtCsBYk5jWoZnZRJPy5uUwzktAY
✔ Secure pool initialization doesn't allow wrong vault
And that's it! Unlike some of the other security vulnerabilities we've discussed, this one is more conceptual and can't be fixed by simply using a particular Anchor type. You'll need to think through the architecture of your program and ensure that you aren't sharing PDAs across different domains.
If you want to take a look at the final solution code you can find it on the
solution branch of
the same 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 look for potential vulnerabilities in its PDA structure. PDAs used for signing should be narrow and focused on a single domain as much as possible.
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.