Skip to content

Latest commit

 

History

History
122 lines (93 loc) · 6.98 KB

mitigations.md

File metadata and controls

122 lines (93 loc) · 6.98 KB

Mitigation Strategies Analysis for bytecodealliance/wasmtime

Mitigation Strategy: Fine-Grained Resource Limits (Wasmtime Config)

1. Fine-Grained Resource Limits (Wasmtime Config)

  • Description:

    1. Identify Baseline: Run the Wasm module under normal operating conditions and monitor its resource usage (CPU, memory, fuel, table elements, etc.).
    2. Configure Wasmtime: Modify the wasmtime::Config object before creating the Engine.
      • set_max_memory(size): Set size to a value slightly above the observed baseline memory usage, but significantly lower than the system's total memory.
      • set_max_table_elements(count): Set count based on the expected number of indirect function calls.
      • set_max_instances(count): Limit the number of instances.
      • set_max_tables(count): Limit the number of tables.
      • set_max_memories(count): Limit the number of memories.
      • set_consume_fuel(true): Enable fuel consumption.
      • set_fuel_consumed(initial_fuel): Set initial_fuel to a value that allows for a reasonable execution time, based on testing. Experiment to find the right balance.
      • epoch_interruption: Enable and configure. Set a reasonable interval (e.g., every 100ms).
    3. Implement Fuel Consumption (Host Calls): Within host functions (WASI or custom), use Caller::consume_fuel(amount) to deduct fuel based on the computational cost of the operation. This requires careful profiling and estimation.
    4. Handle Resource Exhaustion: In your host code, check for Trap::OutOfFuel or other resource-related traps after calling Wasm functions. Handle these gracefully (e.g., return an error, log the event, terminate the instance).
    5. Monitor and Adjust: Continuously monitor resource usage and adjust the limits as needed.
    6. Custom Resource Limiter: If needed, implement ResourceLimiter trait.

  • Threats Mitigated:

    • Resource Exhaustion (Denial of Service): (Severity: High) - Prevents a malicious module from consuming excessive CPU, memory, or other resources.
    • Infinite Loops: (Severity: High) - Fuel consumption and epoch interruption prevent infinite loops.
    • Excessive Table/Instance/Memory Growth: (Severity: Medium) - Limits sizes.

  • Impact:

    • Resource Exhaustion: Significantly reduces the risk.
    • Infinite Loops: Eliminates the risk.
    • Excessive Growth: Reduces the risk to a manageable level.

  • Currently Implemented:

    • Config::max_memory() is set in src/engine.rs.
    • Fuel consumption is enabled in src/engine.rs.
    • Epoch interruption is enabled in src/engine.rs.

  • Missing Implementation:

    • consume_fuel calls are missing in several host functions in src/host_functions.rs.
    • max_table_elements, max_instances, max_tables, max_memories are not currently configured.
    • Robust error handling for Trap::OutOfFuel is partially implemented.
    • Custom ResourceLimiter is not implemented.

Mitigation Strategy: Strict WASI Permissions (WasiCtxBuilder)

2. Strict WASI Permissions (WasiCtxBuilder)

  • Description:

    1. Identify Required Capabilities: Analyze the Wasm module's functionality to determine the minimum set of WASI capabilities it needs.
    2. Configure WasiCtxBuilder:
      • inherit_stdio(false): Disable inheritance of standard I/O streams.
      • inherit_env(false): Disable inheritance of environment variables.
      • preopened_dir(dir, guest_path): Only pre-open specific directories. Use a dedicated, sandboxed directory. Set appropriate permissions on dir. guest_path specifies how the directory appears to the Wasm module.
      • env(key, value): Set only essential environment variables.
      • args(args): Carefully control the command-line arguments.
    3. Avoid Unnecessary Capabilities: Do not grant capabilities like fd_fdstat_set_flags, path_open with broad permissions, or network access unless absolutely necessary.
    4. Review and Audit: Regularly review the WASI configuration.

  • Threats Mitigated:

    • Unauthorized File System Access: (Severity: High)
    • Unauthorized Network Access: (Severity: High)
    • Information Disclosure (Environment): (Severity: Medium)
    • Command Injection: (Severity: Medium)

  • Impact:

    • Unauthorized File/Network Access: Significantly reduces the risk.
    • Information Disclosure/Command Injection: Reduces the risk.

  • Currently Implemented:

    • WasiCtxBuilder is used in src/wasi_context.rs.
    • A single pre-opened directory is configured.
    • inherit_stdio and inherit_env are set to false.

  • Missing Implementation:

    • The pre-opened directory's permissions might be too permissive.
    • Audit the args passed to the Wasm module.
    • Consider separate WasiCtx instances for different modules.

Mitigation Strategy: Wasm Module Validation (Module::validate)

3. Wasm Module Validation (Module::validate)

  • Description:

    1. Obtain Wasm Bytes: Load the WebAssembly module's bytecode into a byte vector (Vec<u8>).
    2. Validate: Call Module::validate(&store, &wasm_bytes).
    3. Handle Errors: If Module::validate returns an error, do not proceed. Log the error and reject the module.

  • Threats Mitigated:

    • Malformed Wasm Bytecode: (Severity: Medium)
    • Invalid Wasm Constructs: (Severity: Medium)

  • Impact:

    • Malformed Bytecode/Invalid Constructs: Eliminates the risk.

  • Currently Implemented:

    • Module::validate is called in src/engine.rs.

  • Missing Implementation:

    • None.

Mitigation Strategy: Stay Updated (Wasmtime Dependency)

4. Stay Updated (Wasmtime Dependency)

  • Description:

    1. Monitor Releases: Regularly check the Wasmtime GitHub repository for new releases and security advisories.
    2. Update Promptly: When a new version of Wasmtime is released (especially with security fixes), update the project's dependency.
    3. Test After Update: Thoroughly test the application after updating Wasmtime.

  • Threats Mitigated:

    • Wasmtime Vulnerabilities: (Severity: Variable, potentially High)

  • Impact:

    • Wasmtime Vulnerabilities: Significantly reduces the risk.

  • Currently Implemented:

    • The project's Cargo.toml file specifies the Wasmtime dependency.

  • Missing Implementation:

    • A formal process for monitoring releases and applying updates is not yet in place.
    • Automated testing after Wasmtime updates is not fully implemented.