mitigations.md

Mitigation Strategies Analysis for fuellabs/sway

Mitigation Strategy: Enforce Strict Gas Limits (Sway-Specific)

• Description:

  1. Analyze Gas Costs: Use forc build --gas-estimation and any available Sway-specific profiling tools to get precise gas cost estimates for each function. Focus on Sway constructs like loops, storage access (reads/writes), and complex data structure manipulations.
  2. Set Realistic Limits (Sway Attribute): Use the #[payable(gas_limit = X)] attribute directly in your Sway code. This is a Sway-level enforcement mechanism. Choose X carefully, balancing a small safety margin with preventing DoS.
  3. Test with Gas Limits (Sway Testing): Use forc test and ensure your test suite includes scenarios that approach the gas limits. This verifies the limits are correctly enforced by the FuelVM.
  4. Iterate and Refine: As the Sway compiler and FuelVM evolve, gas costs will change. Re-run gas estimation and adjust the gas_limit attribute in your Sway code periodically.

• Threats Mitigated:

  • Resource Exhaustion DoS (High Severity): Directly prevents Sway code from executing beyond the specified gas limit, stopping DoS attacks that rely on expensive operations.
  • Unexpectedly High Transaction Costs (Medium Severity): Provides a hard limit within the Sway code itself, preventing users from accidentally submitting overly expensive transactions.

• Impact:

  • Resource Exhaustion DoS: Very high impact. This is a primary defense against gas-based DoS.
  • Unexpectedly High Transaction Costs: High impact, as it sets a contract-enforced limit.

• Currently Implemented:

  • #[payable(gas_limit = 500000)] is used on the mint and transfer functions in token.sw.

• Missing Implementation:

  • #[payable(gas_limit = ...)] is missing on the approve function.
  • Gas cost analysis and attribute updates are needed after recent Sway code modifications.

Mitigation Strategy: Input Validation and Size Limits (Sway Code)

• Description:

  1. Identify Sway Inputs: For every Sway function, identify all input parameters (arrays, strings, structs, etc.).
  2. Define Constraints (Sway Types & Logic): Use Sway's type system (e.g., fixed-size arrays [u8; 32]) and require() statements within the Sway code to define and enforce constraints. Example: require(input_array.len() <= MAX_ARRAY_LENGTH, "Input array too large");
  3. Sway-Specific Checks: Leverage Sway's features for validation. For example, if you have an enum, ensure input values are valid members of that enum.
  4. Test with Invalid Inputs (Sway Tests): Write forc test cases that deliberately provide invalid inputs to your Sway functions, verifying the require() statements and type checks work as expected.

• Threats Mitigated:

  • Resource Exhaustion DoS (High Severity): Prevents Sway code from processing excessively large inputs that could lead to high gas consumption.
  • Logic Errors (Medium Severity): Ensures Sway functions only receive data conforming to expected types and ranges, preventing unexpected behavior.

• Impact:

  • Resource Exhaustion DoS: High impact, as it stops oversized inputs at the Sway code level.
  • Logic Errors: Medium-high impact, improving the robustness of the Sway code.

• Currently Implemented:

  • require(message.len() <= 256, "Message too long"); in send_message function.

• Missing Implementation:

  • Missing size limits on arrays passed to process_data.
  • No validation of user_id string format.

Mitigation Strategy: Use Checked Arithmetic Operations (Sway Intrinsics)

• Description:

  1. Identify Arithmetic (Sway Code): Locate all instances of +, -, *, / in your Sway code.
  2. Replace with Sway Intrinsics: Replace every unchecked operator with its Sway-provided checked counterpart: checked_add, checked_sub, checked_mul, checked_div. These are intrinsic to Sway.
  3. Handle Option (Sway Pattern Matching): The checked functions return an Option<u64>. Use Sway's match statement or unwrap_or to handle the None case (overflow/underflow), typically reverting the transaction using revert(ERROR_CODE);.
  4. Test Overflow/Underflow (Sway Tests): Write forc test cases that specifically cause overflows and underflows, verifying your Sway code handles them correctly.

• Threats Mitigated:

  • Arithmetic Overflows/Underflows (High Severity): Completely prevents vulnerabilities arising from integer overflows and underflows in Sway code.

• Impact:

  • Arithmetic Overflows/Underflows: Extremely high impact. This is the fundamental mitigation.

• Currently Implemented:

  • checked_add and checked_mul are used in calculate_reward.

• Missing Implementation:

  • Unchecked - is used in update_balance. This must be changed to checked_sub.

Mitigation Strategy: Effects-Interaction Pattern (Sway Code Structure)

• Description:

  1. Structure Sway Functions: Organize each Sway function in this order:
     • Checks (Sway require): All input validation, authorization (using msg_sender()), and preconditions, implemented using require() statements in Sway.
     • Effects (Sway State Updates): Modify the contract's state (storage variables) only after all checks pass. Use Sway's assignment operators.
     • Interactions (Sway call): Make external calls to other contracts (using Sway's call mechanism) after state updates.
  2. Minimize Post-Interaction State Changes (Sway Discipline): Strictly avoid modifying Sway's contract state after an external call, unless absolutely unavoidable (and then use extreme caution and consider Sway-compatible mutexes if available).

• Threats Mitigated:

  • Reentrancy-Like Issues (Medium Severity): Reduces the risk, even though Sway prevents direct reentrancy to the same contract. Focuses on safe interaction between Sway contracts.

• Impact:

  • Reentrancy-Like Issues: Medium-high impact, by enforcing a safe calling pattern within the Sway code.

• Currently Implemented:

  • transfer function mostly follows this pattern.

• Missing Implementation:

  • claim_rewards calls an external contract before updating the user's balance in Sway storage. This needs refactoring.

Mitigation Strategy: Avoid Unsafe asm Blocks (Sway Code Choice)

• Description:

  1. Prioritize Sway: Use Sway's built-in functions, standard library, and language features exclusively whenever possible.
  2. Justification and Documentation (If Unavoidable): If asm is absolutely required, provide a very strong justification and extremely detailed documentation within the Sway code itself, explaining why Sway's features are insufficient and outlining the asm block's precise behavior and risks.
  3. Isolation (Sway Code Organization): Keep asm blocks as small and self-contained as possible within the Sway code.
  4. Extensive Sway-Level Testing: Even with asm, write as many forc test cases as possible to test the surrounding Sway code and the overall contract behavior, including edge cases and potential interactions with the asm block.

• Threats Mitigated:

  • Memory Safety Violations (High Severity): asm bypasses Sway's memory safety. Avoiding it eliminates this risk entirely.
  • Logic Errors (High Severity): Incorrect asm can cause arbitrary, hard-to-debug issues.
  • Non-Deterministic Behavior (Medium Severity): asm might behave differently across FuelVM versions.

• Impact:

  • All Threats: Extremely high impact if asm is avoided completely.

• Currently Implemented:

  • No asm blocks are currently used in the project.

• Missing Implementation:

  • N/A (since asm is avoided)

Mitigation Strategy: Leverage Sway's Type System (Sway Type Definitions)

• Description:

  1. Define Custom Sway Types: Use struct and enum extensively to create custom types that precisely model your data. Avoid generic types (like u64) where a more specific Sway type (e.g., Balance, UserID) is appropriate.
  2. Sway Type Aliases: Use type aliases to give meaningful names to complex Sway types, improving readability.
  3. Enforce Constraints (Sway Compiler): Let the Sway compiler enforce type constraints. For example, if a value should only be one of a few options, use a Sway enum.
  4. Review for Shadowing (Sway Code Review): Carefully examine your Sway code for any instances of variable shadowing.

• Threats Mitigated:

  • Type Confusion Errors (Medium Severity): The Sway compiler will prevent many type-related errors.
  • Logic Errors (Medium Severity): Clearer Sway types make the code easier to understand and maintain, reducing logic errors.
  • Shadowing-Related Bugs (Medium Severity): Prevents unexpected behavior.

• Impact:

  • Type Confusion Errors: High impact, as the Sway compiler enforces type safety.
  • Logic Errors: Medium impact, by improving code clarity.
  • Shadowing-Related Bugs: Medium impact.

• Currently Implemented:

  • struct User and struct Asset are defined.
  • enum TransactionState is used.

• Missing Implementation:

  • More specific Sway types could be used in some areas (e.g., a Balance type instead of just u64).
  • A code review focused on Sway-specific shadowing is needed.