Skip to content

Latest commit

 

History

History
150 lines (119 loc) · 11.6 KB

mitigations.md

File metadata and controls

150 lines (119 loc) · 11.6 KB

Mitigation Strategies Analysis for solana-labs/solana

Mitigation Strategy: Strict CPI Ordering and Reentrancy Guards (Solana-Specific)

Description:

  1. Analyze CPI Flow (Solana Context): Thoroughly map out all cross-program invocations (CPIs) within your Solana program. Identify any potential for recursive calls back into your own program via other Solana programs. This is crucial because Solana's single-threaded execution within an instruction doesn't prevent reentrancy across CPIs.
  2. State Updates Before CPIs: Structure your Solana program's logic so that all state changes (modifications to Solana account data) are completed before any CPIs are made. This leverages Solana's account model to ensure consistency.
  3. Reentrancy Guard Implementation (Solana-Specific):
    • Use a Solana account (or a field within an existing Solana account) to store the reentrancy guard. This leverages Solana's state management.
    • At the beginning of your Solana program's entry point, check the guard. If locked, return a ProgramError.
    • Immediately set the guard to locked.
    • At the end of your Solana program's entry point (even on error), reset the guard. Use a pattern that guarantees this reset, even with Solana's error handling.
    • For CPI-aware guards (essential on Solana), use a counter. Increment before the CPI, decrement after. Only allow execution if the counter is zero initially. This accounts for Solana's CPI depth limits.
  4. Post-CPI Validation (Solana Accounts): After each CPI, re-validate the state of your program's Solana accounts. The called program might have modified them. This is critical in Solana's mutable account model.

  • Threats Mitigated:

    • CPI Reentrancy (Solana-Specific): (Severity: Critical) - Prevents attackers from recursively calling your Solana program via CPIs to manipulate state, steal funds, or bypass security checks. This is unique to Solana's CPI mechanism.
    • Logic Errors (Solana State): (Severity: High) - Reduces logic errors from inconsistent Solana account state due to CPIs.
    • Data Corruption (Solana Accounts): (Severity: High) - Post-CPI validation prevents data corruption in Solana accounts by external programs.

  • Impact:

    • CPI Reentrancy: Risk reduced from Critical to Low.
    • Logic Errors: Risk reduced from High to Medium.
    • Data Corruption: Risk reduced from High to Medium.

  • Currently Implemented: (Hypothetical Project)

    • Partially. Reentrancy guards (boolean) in programs/token_transfer/src/lib.rs. CPI ordering mostly followed, but post-CPI validation is inconsistent.

  • Missing Implementation:

    • CPI-aware guards (counters) missing for instructions with multiple CPIs (e.g., batch_transfer).
    • Post-CPI validation missing in handlers interacting with custom oracles.
    • Consistent guard reset pattern (like finally) is not used, risking human error.

Mitigation Strategy: Account Ownership and PDA Validation (Solana-Specific)

Description:

  1. Ownership Checks (Solana Account Model): At the start of each instruction handler, verify the ownership of all Solana accounts passed.
    • account_info.is_signer: Check if a Solana account has signed (for signer accounts).
    • account_info.owner == program_id: Check if a Solana account is owned by your program.
    • account_info.owner == expected_owner: Check if a Solana account is owned by a specific program (e.g., the Token Program). This is crucial for interacting with other Solana programs.
  2. PDA Derivation (Solana-Specific):
    • When using a PDA (Program Derived Address), always re-derive it within your Solana program using Pubkey::find_program_address(&[seeds], &program_id).
    • Compare the re-derived PDA to the one provided in the instruction data. Return a ProgramError if they don't match.
    • Never trust a user-provided PDA without this verification. This is fundamental to Solana's security model.
  3. Seeds Validation (Solana PDAs): Carefully validate the seeds used for PDA derivation. Ensure they are the correct type/length and prevent predictable PDAs.
  4. Bump Seed Handling (Solana PDAs): Store the bump seed securely within the Solana account data. Use it consistently and protect it from modification.

  • Threats Mitigated:

    • Unauthorized Account Access (Solana Accounts): (Severity: Critical) - Prevents unauthorized access to Solana accounts.
    • PDA Manipulation (Solana-Specific): (Severity: Critical) - Prevents attackers from using incorrect or malicious PDAs. This is unique to Solana.
    • Account Substitution (Solana Accounts): (Severity: High) - Prevents substituting one Solana account for another.

  • Impact:

    • Unauthorized Access: Risk reduced from Critical to Low.
    • PDA Manipulation: Risk reduced from Critical to Low.
    • Account Substitution: Risk reduced from High to Low.

  • Currently Implemented: (Hypothetical Project)

    • Mostly. Ownership checks and PDA validation are common.

  • Missing Implementation:

    • Missing ownership checks for some configuration/metadata accounts.
    • Incomplete seeds validation, potentially allowing edge-case PDA manipulation.
    • Inconsistent bump seed handling.

Mitigation Strategy: Compute Unit Budgeting and Optimization (Solana-Specific)

Description:

  1. Profiling (Solana Compute Units): Use Solana's profiling tools to measure the compute unit consumption of your program's instructions. Identify hotspots.
  2. Algorithm Optimization (for Compute Units): Optimize algorithms and data structures to reduce computational complexity, specifically to minimize Solana compute unit usage.
  3. Loop Optimization (Solana Limits): Minimize loop iterations. Avoid nested loops. If iterating over many Solana accounts, use pagination to stay within compute unit limits.
  4. CPI Optimization (Solana Costs): Minimize CPI calls, as each consumes Solana compute units.
  5. Data Structure Size (Solana Serialization): Minimize Solana account data structure size to reduce serialization/deserialization compute unit costs.
  6. Conditional Logic (Solana Efficiency): Use if statements to avoid unnecessary computations, saving Solana compute units.
  7. Early Exits (Solana Cost Reduction): Return early from instruction handlers if preconditions are not met, to save compute units.

  • Threats Mitigated:

    • Denial of Service (DoS) (Solana Compute Units): (Severity: High) - Reduces the risk of exceeding Solana's compute unit limits. This is unique to Solana's resource model.
    • Transaction Failures (Solana Limits): (Severity: Medium) - Reduces failures due to excessive compute unit consumption.

  • Impact:

    • DoS: Risk reduced from High to Medium.
    • Transaction Failures: Risk reduced from Medium to Low.

  • Currently Implemented: (Hypothetical Project)

    • Partially. Some basic optimization.

  • Missing Implementation:

    • Comprehensive profiling and optimization not done.
    • Inefficient loops and data structures present.
    • CPI calls not always minimized.
    • No specific compute unit budget enforced.

Mitigation Strategy: Rent Exemption (Solana-Specific)

Description:

  1. Identify All Accounts (Solana): Identify all Solana accounts your program creates.
  2. Calculate Minimum Balance (Solana Rent): Use Rent::get()?.minimum_balance(account_data_len) to calculate the minimum balance for rent exemption. account_data_len is the Solana account data size in bytes. This is entirely Solana-specific.
  3. Ensure Sufficient Lamports (Solana): When creating a Solana account, fund it with at least the minimum balance for rent exemption.
  4. Handle Insufficient Funds (Solana): If insufficient lamports, return a ProgramError.
  5. Reallocation (Solana Rent): If increasing a Solana account's size, increase lamports to maintain rent exemption. Use reallocate and transfer lamports.

  • Threats Mitigated:

    • Account Deletion (Solana Rent): (Severity: High) - Prevents Solana accounts from being deleted due to insufficient rent. This is unique to Solana.
    • Data Loss (Solana Accounts): (Severity: High) - Prevents data loss from account deletion.
    • Program Failure (Solana Dependencies): (Severity: High) - Prevents failures if a relied-upon Solana account is deleted.

  • Impact:

    • Account Deletion: Risk reduced from High to Low.
    • Data Loss: Risk reduced from High to Low.
    • Program Failure: Risk reduced from High to Low.

  • Currently Implemented: (Hypothetical Project)

    • Mostly. Most account creation functions ensure rent exemption.

  • Missing Implementation:

    • Some older functions don't properly handle rent exemption.
    • Reallocation logic doesn't always maintain rent exemption.

Mitigation Strategy: Strict Schema Definition and Account Data Validation (Solana-Focused)

Description:

  1. Borsh Schema (Solana Serialization): Define clear borsh schemas for all Solana account data structures and instruction data. Use Rust structs and enums. Borsh is the default and recommended serialization format for Solana.
  2. Discriminator Fields (Solana Type Safety): Include discriminator fields (enums or unique IDs) to distinguish between different Solana account types or instruction variants. This is crucial to prevent type confusion attacks within Solana's account model.
  3. Deserialization (Solana Borsh): Use borsh::try_from_slice to deserialize Solana account and instruction data.
  4. Post-Deserialization Validation (Solana Accounts): Immediately after deserialization, validate the data within a dedicated function (e.g., validate(&self)).
    • Check discriminator field values.
    • Verify field ranges.
    • Ensure field relationships are consistent.
    • Check any other invariants.
  5. Error Handling (Solana ProgramError): If validation fails, return a specific ProgramError.

  • Threats Mitigated:

    • Type Confusion/Deserialization Errors (Solana-Specific): (Severity: Critical) - Prevents attackers from misinterpreting data intended for one Solana account type as another. This is specific to how Solana handles account data.
    • Data Corruption (Solana Accounts): (Severity: High) - Ensures Solana account data validity.
    • Logic Errors (Solana State): (Severity: Medium) - Reduces logic errors from invalid Solana account data.

  • Impact:

    • Type Confusion: Risk reduced from Critical to Low.
    • Data Corruption: Risk reduced from High to Low.
    • Logic Errors: Risk reduced from Medium to Low.

  • Currently Implemented: (Hypothetical Project)

    • Partially. Borsh schemas are defined, and deserialization is used. Discriminators are used in some cases.

  • Missing Implementation:

    • Comprehensive post-deserialization validation functions (validate(&self)) are missing for many account types. Validation is ad-hoc, leading to inconsistencies.
    • Discriminator fields are not consistently used.
    • Some older account types use custom serialization instead of borsh.