substrate-vulnerability-scanner（基板漏洞扫描仪）

Substrate Vulnerability Scanner

1. Purpose

Systematically scan Substrate runtime modules (pallets) for platform-specific security vulnerabilities that can cause node crashes, DoS attacks, or unauthorized access. This skill encodes 7 critical vulnerability patterns unique to Substrate/FRAME-based chains.

2. When to Use This Skill

• Auditing custom Substrate pallets
• Reviewing FRAME runtime code
• Pre-launch security assessment of Substrate chains (Polkadot parachains, standalone chains)
• Validating dispatchable extrinsic functions
• Reviewing weight calculation functions
• Assessing unsigned transaction validation logic

3. Platform Detection

File Extensions & Indicators

• Rust files: .rs

Language/Framework Markers

// Substrate/FRAME indicators
#[pallet]
pub mod pallet {
    use frame_support::pallet_prelude::*;
    use frame_system::pallet_prelude::*;

    #[pallet::config]
    pub trait Config: frame_system::Config { }

    #[pallet::call]
    impl<T: Config> Pallet<T> {
        #[pallet::weight(10_000)]
        pub fn example_function(origin: OriginFor<T>) -> DispatchResult { }
    }
}

// Common patterns
DispatchResult, DispatchError
ensure!, ensure_signed, ensure_root
StorageValue, StorageMap, StorageDoubleMap
#[pallet::storage]
#[pallet::call]
#[pallet::weight]
#[pallet::validate_unsigned]

Project Structure

• pallets/*/lib.rs - Pallet implementations
• runtime/lib.rs - Runtime configuration
• benchmarking.rs - Weight benchmarks
• Cargo.toml with frame-* dependencies

Tool Support

• cargo-fuzz: Fuzz testing for Rust
• test-fuzz: Property-based testing framework
• benchmarking framework: Built-in weight calculation
• try-runtime: Runtime migration testing

4. How This Skill Works

When invoked, I will:

1. Search your codebase for Substrate pallets
2. Analyze each pallet for the 7 vulnerability patterns
3. Report findings with file references and severity
4. Provide fixes for each identified issue
5. Check weight calculations and origin validation

5. Vulnerability Patterns (7 Critical Patterns)

I check for 7 critical vulnerability patterns unique to Substrate/FRAME. For detailed detection patterns, code examples, mitigations, and testing strategies, see VULNERABILITY_PATTERNS.md.

Pattern Summary:

1. Arithmetic Overflow ⚠️ CRITICAL

- Direct +, -, *, / operators wrap in release mode - Must use checked_* or saturating_* methods - Affects balance/token calculations, reward/fee math

1. Don't Panic ⚠️ CRITICAL - DoS

- Panics cause node to stop processing blocks - No unwrap(), expect(), array indexing without bounds check - All user input must be validated with ensure!

1. Weights and Fees ⚠️ CRITICAL - DoS

- Incorrect weights allow spam attacks - Fixed weights for variable-cost operations enable DoS - Must use benchmarking framework, bound all input parameters

1. Verify First, Write Last ⚠️ HIGH (Pre-v0.9.25)

- Storage writes before validation persist on error (pre-v0.9.25) - Pattern: validate → write → emit event - Upgrade to v0.9.25+ or use manual #[transactional]

1. Unsigned Transaction Validation ⚠️ HIGH

- Insufficient validation allows spam/replay attacks - Prefer signed transactions - If unsigned: validate parameters, replay protection, authenticate source

1. Bad Randomness ⚠️ MEDIUM

- pallet_randomness_collective_flip vulnerable to collusion - Must use BABE randomness (pallet_babe::RandomnessFromOneEpochAgo) - Use random(subject) not random_seed()

1. Bad Origin ⚠️ CRITICAL

- ensure_signed allows any user for privileged operations - Must use ensure_root or custom origins (ForceOrigin, AdminOrigin) - Origin types must be properly configured in runtime

For complete vulnerability patterns with code examples, see VULNERABILITY_PATTERNS.md.

6. Scanning Workflow

Step 1: Platform Identification

1. Verify Substrate/FRAME framework usage
2. Check Substrate version (v0.9.25+ has transactional storage)
3. Locate pallet implementations (pallets/*/lib.rs)
4. Identify runtime configuration (runtime/lib.rs)

Step 2: Dispatchable Analysis

For each #[pallet::call] function:

• Arithmetic: Uses checked/saturating operations?
• Panics: No unwrap/expect/indexing?
• Weights: Proportional to cost, bounded inputs?
• Origin: Appropriate validation level?
• Validation: All checks before storage writes?

Step 3: Panic Sweep

# Search for panic-prone patterns
rg "unwrap\(\)" pallets/
rg "expect\(" pallets/
rg "\[.*\]" pallets/  # Array indexing
rg " as u\d+" pallets/  # Type casts
rg "\.unwrap_or" pallets/

Step 4: Arithmetic Safety Check

# Find direct arithmetic
rg " \+ |\+=| - |-=| \* |\*=| / |/=" pallets/

# Should find checked/saturating alternatives instead
rg "checked_add|checked_sub|checked_mul|checked_div" pallets/
rg "saturating_add|saturating_sub|saturating_mul" pallets/

Step 5: Weight Analysis

• Run benchmarking: cargo test --features runtime-benchmarks
• Verify weights match computational cost
• Check for bounded input parameters
• Review weight calculation functions

Step 6: Origin & Privilege Review

# Find privileged operations
rg "ensure_signed" pallets/ | grep -E "pause|emergency|admin|force|sudo"

# Should use ensure_root or custom origins
rg "ensure_root|ForceOrigin|AdminOrigin" pallets/

Step 7: Testing Review

• Unit tests cover all dispatchables
• Fuzz tests for panic conditions
• Benchmarks for weight calculation
• try-runtime tests for migrations

7. Priority Guidelines

Critical (Immediate Fix Required)

• Arithmetic overflow (token creation, balance manipulation)
• Panic DoS (node crash risk)
• Bad origin (unauthorized privileged operations)

High (Fix Before Launch)

• Incorrect weights (DoS via spam)
• Verify-first violations (state corruption, pre-v0.9.25)
• Unsigned validation issues (spam, replay attacks)

Medium (Address in Audit)

• Bad randomness (manipulation possible but limited impact)

8. Testing Recommendations

Fuzz Testing

// Use test-fuzz for property-based testing
#[cfg(test)]
mod tests {
    use test_fuzz::test_fuzz;

    #[test_fuzz]
    fn fuzz_transfer(from: AccountId, to: AccountId, amount: u128) {
        // Should never panic
        let _ = Pallet::transfer(from, to, amount);
    }

    #[test_fuzz]
    fn fuzz_no_panics(call: Call) {
        // No dispatchable should panic
        let _ = call.dispatch(origin);
    }
}

Benchmarking

# Run benchmarks to generate weights
cargo build --release --features runtime-benchmarks
./target/release/node benchmark pallet \
    --chain dev \
    --pallet pallet_example \
    --extrinsic "*" \
    --steps 50 \
    --repeat 20

try-runtime

# Test runtime upgrades
cargo build --release --features try-runtime
try-runtime --runtime ./target/release/wbuild/runtime.wasm \
    on-runtime-upgrade live --uri wss://rpc.polkadot.io

9. Additional Resources

• Building Secure Contracts: building-secure-contracts/not-so-smart-contracts/substrate/
• Substrate Documentation: https://docs.substrate.io/
• FRAME Documentation: https://paritytech.github.io/substrate/master/frame_support/
• test-fuzz: https://github.com/trailofbits/test-fuzz
• Substrate StackExchange: https://substrate.stackexchange.com/

10. Quick Reference Checklist

Before completing Substrate pallet audit:

Arithmetic Safety (CRITICAL):

• No direct +, -, *, / operators in dispatchables
• All arithmetic uses checked_* or saturating_*
• Type conversions use try_into() with error handling

Panic Prevention (CRITICAL):

• No unwrap() or expect() in dispatchables
• No direct array/slice indexing without bounds check
• All user inputs validated with ensure!
• Division operations check for zero divisor

Weights & DoS (CRITICAL):

• Weights proportional to computational cost
• Input parameters have maximum bounds
• Benchmarking used to determine weights
• No free (zero-weight) expensive operations

Access Control (CRITICAL):

• Privileged operations use ensure_root or custom origins
• ensure_signed only for user-level operations
• Origin types properly configured in runtime
• Sudo pallet removed before production

Storage Safety (HIGH):

• Using Substrate v0.9.25+ OR manual #[transactional]
• Validation before storage writes
• Events emitted after successful operations

Other (MEDIUM):

• Unsigned transactions use signed alternative if possible
• If unsigned: proper validation, replay protection, authentication
• BABE randomness used (not RandomnessCollectiveFlip)
• Randomness uses random(subject) not random_seed()

Testing:

• Unit tests for all dispatchables
• Fuzz tests to find panics
• Benchmarks generated and verified
• try-runtime tests for migrations