Skip to content

Latest commit

 

History

History
178 lines (128 loc) · 9.55 KB

threat-modeling.md

File metadata and controls

178 lines (128 loc) · 9.55 KB

Threat Model Analysis for fuellabs/fuels-rs

Threat: Malicious Fuel Node Impersonation (Spoofing)

  • Threat: Malicious Fuel Node Impersonation (Spoofing)

    • Description: An attacker sets up a rogue Fuel node and configures the application (or tricks the user) to connect to it. The rogue node feeds the fuels-rs SDK with fabricated data (false confirmations, balances, block data). The attacker might use a similar-looking URL or exploit a vulnerability in the application's node selection.

    • Impact:

      • Application believes false blockchain state.
      • User fund loss due to incorrect confirmations.
      • Incorrect application decisions based on false data.
      • Loss of user trust.

    • fuels-rs Component Affected:

      • Provider (URL/connection configuration).
      • Functions relying on Provider data: get_balance, get_transaction, get_block, etc.

    • Risk Severity: Critical

    • Mitigation Strategies:

      • Hardcode Trusted Node URLs (with caution and update mechanism): For high-security applications, consider hardcoding reputable node URLs. Crucially, include a secure mechanism to update these URLs.
      • Trusted Node Provider List: Use a securely fetched and authenticated list of trusted node providers.
      • Quorum-Based Approach: Connect to multiple Provider instances (different nodes) and require consensus (e.g., 2/3 agreement) before accepting data.
      • Light Client (Future): Utilize a Fuel light client (when available) for independent blockchain data verification.
      • User Education: Educate users on the risks of untrusted nodes and secure configuration.

Threat: Fake Contract ABI (Spoofing)

  • Threat: Fake Contract ABI (Spoofing)

    • Description: An attacker provides a manipulated ABI JSON, causing fuels-rs to misinterpret contract calls. This could happen through a compromised ABI server, user deception, or an application vulnerability in ABI loading.

    • Impact:

      • Incorrect contract interactions.
      • Potential exploitation of contract vulnerabilities.
      • Application malfunction.
      • Data corruption.

    • fuels-rs Component Affected:

      • abigen! macro.
      • Contract::load_from (if loading from file).
      • Contract::from_json_file (if loading from file).
      • Functions interacting with contracts using the ABI.

    • Risk Severity: High

    • Mitigation Strategies:

      • abigen! with Embedded ABIs: Embed the ABI JSON directly into the code using abigen!. Example: abigen!(MyContract, "path/to/abi.json"); (path relative to project root, included at compile time).
      • Verify ABI Hash: Before loading from an external source, calculate the ABI's hash (e.g., SHA-256) and compare it to a known good hash from a trusted source.
      • Avoid Dynamic ABI Loading: Do not load ABIs from untrusted sources at runtime. If necessary, implement strict validation and sandboxing.

Threat: Transaction Manipulation Before Signing (Tampering)

  • Threat: Transaction Manipulation Before Signing (Tampering)

    • Description: An attacker with access to application memory or communication intercepts and modifies transaction parameters before fuels-rs signs the transaction.

    • Impact:

      • Funds sent to attacker's address.
      • Unauthorized contract calls.
      • Loss of user funds.

    • fuels-rs Component Affected:

      • Wallet::sign_transaction
      • TransactionBuilder (and related structs).
      • Functions preparing transactions for signing.

    • Risk Severity: Critical

    • Mitigation Strategies:

      • Secure Memory Management: Leverage Rust's ownership and borrowing to minimize memory corruption. Avoid unsafe code unless thoroughly audited.
      • Hardware Wallet Integration: Use a hardware wallet (if supported by fuels-rs or via a bridge) for signing.
      • Transaction Review: Display a clear transaction summary to the user for confirmation before signing.
      • Multi-Signature Wallets: Use multi-signature wallets for high-value transactions.
      • Secure Enclaves (if available): Use secure enclaves (e.g., Intel SGX, ARM TrustZone) to protect signing.

Threat: Dependency Tampering (Supply Chain Attack) (Tampering)

  • Threat: Dependency Tampering (Supply Chain Attack) (Tampering)

    • Description: An attacker compromises a dependency of fuels-rs (or fuels-rs itself) and injects malicious code.

    • Impact:

      • Complete application compromise.
      • Loss of user funds.
      • Data theft.
      • Reputational damage.

    • fuels-rs Component Affected: Potentially any component.

    • Risk Severity: Critical

    • Mitigation Strategies:

      • cargo vet: Audit dependencies with cargo vet.
      • cargo crev: Use cargo crev for community reviews.
      • Dependency Pinning: Pin dependencies to specific versions in Cargo.toml. Regularly review and update.
      • Regular Dependency Audits: Audit dependencies for vulnerabilities.
      • Private Registry (for critical dependencies): Consider a private registry for sensitive applications.
      • Monitor Security Advisories: Subscribe to security advisories for fuels-rs and dependencies.

Threat: Private Key Leakage (Information Disclosure)

  • Threat: Private Key Leakage (Information Disclosure)

    • Description: The application exposes private keys through logging, error messages, insecure storage, or unencrypted transmission.

    • Impact:

      • Complete loss of funds.
      • Unauthorized account access.

    • fuels-rs Component Affected:

      • Wallet (and functions handling private keys).
      • Code interacting with the Wallet struct.

    • Risk Severity: Critical

    • Mitigation Strategies:

      • Never Log Private Keys: Absolutely never log private keys.
      • Secure Key Storage:
        • Hardware Wallets: Prioritize hardware wallets.
        • Operating System Keychains: Use OS-provided secure key storage.
        • Encrypted Storage: Use strong encryption with a robust KDF if storing keys in files.
        • Environment Variables (with caution): Use environment variables, but be aware of limitations.
      • Avoid Hardcoding Keys: Never hardcode keys in the source code.
      • Code Reviews: Conduct thorough code reviews.
      • Automated Scanning: Use security scanning tools to detect secrets.

Threat: Gas Exhaustion Attacks (Denial of Service)

  • Threat: Gas Exhaustion Attacks (Denial of Service)

    • Description: An attacker crafts transactions that consume excessive gas, disrupting application functionality or causing high costs.

    • Impact:

      • Application unable to interact with the network.
      • Loss of funds due to gas fees.
      • DoS for other users.

    • fuels-rs Component Affected:

      • TransactionBuilder::gas_limit
      • Provider::send_transaction
      • Functions estimating gas costs.

    • Risk Severity: High

    • Mitigation Strategies:

      • Set Appropriate Gas Limits: Always set explicit gas limits using TransactionBuilder::gas_limit.
      • Estimate Gas Costs: Use fuels-rs functions to estimate gas costs before submission.
      • Monitor Gas Prices: Monitor gas prices and adjust limits dynamically.
      • Circuit Breakers: Implement circuit breakers to prevent transaction submission during high gas prices or failures.
      • Rate Limiting: Limit the rate of transaction submissions.

Threat: Incorrect Access Control in Contract Interactions (Elevation of Privilege)

  • Threat: Incorrect Access Control in Contract Interactions (Elevation of Privilege)

    • Description: The application interacts with a smart contract without proper access control, allowing unauthorized actions. This might involve using the wrong Wallet or failing to check permissions.

    • Impact:

      • Unauthorized actions on the contract.
      • Data breaches.
      • Loss of funds.
      • Contract state corruption.

    • fuels-rs Component Affected:

      • ContractCallHandler
      • Wallet (used for the calling account).
      • Functions generating contract calls.

    • Risk Severity: High

    • Mitigation Strategies:

      • Use the Correct Wallet: Ensure the correct Wallet (authorized user) is used for contract calls.
      • Client-Side Access Control: Verify user permissions before making contract calls.
      • Understand Contract Access Control: Thoroughly understand the contract's access control and interact correctly.
      • Role-Based Access Control (RBAC): Map application user roles to contract roles and enforce them.