Skip to content

Latest commit

 

History

History
106 lines (81 loc) · 6.82 KB

mitigations.md

File metadata and controls

106 lines (81 loc) · 6.82 KB

Mitigation Strategies Analysis for facebook/hermes

Mitigation Strategy: Strict Bytecode Verification

  • Description:

    1. Checksum Generation (Build Time): During compilation to Hermes bytecode, generate a SHA-256 hash of the bytecode. Store this securely (e.g., in a build manifest).
    2. Checksum Verification (Runtime): Before loading bytecode, retrieve the pre-calculated hash. Calculate the hash of the loaded bytecode in memory (before deserialization). Compare the two hashes. Abort if they don't match.
    3. Signature Generation (Build Time - Optional but Recommended): Digitally sign the bytecode (or its hash) using a private key. Store the public key in the application.
    4. Signature Verification (Runtime - Optional but Recommended): Before loading (or after checksum verification), verify the signature using the public key. Abort if verification fails.
    5. Format Validation (Runtime): Before execution, thoroughly validate the bytecode's structure:
      • Check each opcode for validity.
      • Verify data types associated with opcodes.
      • Ensure references are within valid bounds.
      • Check for inconsistencies.
    6. Bounds Checking (Runtime): During interpretation, continuously check array accesses, offsets, and lengths are within allocated memory bounds.

  • Threats Mitigated:

    • Arbitrary Code Execution (Severity: Critical): Prevents loading of malicious bytecode.
    • Data Tampering (Severity: High): Detects modifications to the bytecode.
    • Denial of Service (Severity: High): Malformed bytecode could cause crashes; validation helps.

  • Impact:

    • Arbitrary Code Execution: Risk reduced significantly (Critical to Low/Negligible).
    • Data Tampering: Risk reduced significantly (High to Low/Negligible).
    • Denial of Service: Risk reduced (High to Medium/Low).

  • Currently Implemented:

    • Checksum generation/verification in build pipeline (build.gradle, build.sh) and runtime (BytecodeLoader.java / BytecodeLoader.swift).
    • Basic format validation in BytecodeLoader.java / BytecodeLoader.swift.
    • Partial bounds checking within the Hermes engine.

  • Missing Implementation:

    • Signature generation/verification.
    • Comprehensive format validation (current checks are rudimentary).
    • Explicit bounds checking in application code interacting with Hermes (though this is less directly Hermes-related).

Mitigation Strategy: ReDoS Prevention (within Hermes' Regex Engine)

  • Description:

    1. Regex Review: Identify all regular expressions used within JavaScript code that will be executed by Hermes.
    2. Complexity Analysis: Analyze each regex for potential ReDoS vulnerabilities (nested quantifiers, overlapping alternations).
    3. Simplification: Rewrite complex/vulnerable regexes to use safer patterns.
    4. Timeout Implementation (Hermes-Specific): This is the key Hermes-specific part. If Hermes provides a mechanism to set a timeout for regex matching within the engine itself, use it. If not, this mitigation moves to the "less direct" category (and would involve timeouts at the JSI layer, if regex operations were offloaded to native code). The ideal scenario is a timeout within Hermes's regex engine.
    5. Regex Fuzzing (Hermes-Specific): Fuzz test the Hermes engine's regular expression implementation. This is crucial and directly targets Hermes.
    6. Safe Regex Libraries (Optional, but Hermes-relevant): If Hermes allows it (and it likely does, via JSI), consider using a native library with built-in ReDoS protection, and call it from JavaScript running in Hermes.

  • Threats Mitigated:

    • Denial of Service (ReDoS) (Severity: High): Prevents attackers from making the application unresponsive.

  • Impact:

    • Denial of Service (ReDoS): Risk significantly reduced (High to Low/Negligible).

  • Currently Implemented:

    • Some regular expressions are used in InputValidator.js.

  • Missing Implementation:

    • No systematic regex review.
    • No Hermes-specific timeout mechanism is used (or investigated).
    • No fuzzing of Hermes's regex engine.
    • No safe regex libraries are used via JSI.

Mitigation Strategy: Disable Debugger and Profiler in Production (Hermes-Specific)

  • Description:

    1. Build Configuration (Hermes-Specific): Modify build configurations (e.g., CMakeLists.txt) to ensure Hermes's debugger and profiler are disabled in production. This involves Hermes-specific compiler flags/definitions.
    2. Verification: After building, verify that attempts to connect a debugger to the Hermes instance fail.

  • Threats Mitigated:

    • Information Disclosure (Severity: High): Prevents access to sensitive info via debugger/profiler.
    • Code Manipulation (Severity: Critical): Reduces risk of using the debugger to alter behavior.

  • Impact:

    • Information Disclosure: Risk reduced (High to Negligible).
    • Code Manipulation: Risk reduced (Critical to Negligible).

  • Currently Implemented:

    • Debugger disabled via NDEBUG.

  • Missing Implementation:

    • Profiler not explicitly disabled.
    • Verification steps are not part of the release process.

Mitigation Strategy: Memory Management Hardening (within Hermes)

  • Description:

    1. Fuzz Testing (Hermes Internals): Fuzz test the Hermes engine itself, specifically its garbage collector and memory allocation routines. This is the most direct and crucial step.
    2. Memory Safety Tools (Hermes Build): When building Hermes (if you're building from source), use memory safety tools like AddressSanitizer and Valgrind to detect memory errors within Hermes's own codebase.
    3. Stay up to date (Hermes Updates): Keep the version of hermes up to date, because new versions often contains bug fixes and security improvements.

  • Threats Mitigated:

    • Use-After-Free (Severity: Critical):
    • Double-Free (Severity: Critical):
    • Buffer Overflows (Severity: Critical):
    • Denial of Service (Severity: High):

  • Impact:

    • Memory Corruption Vulnerabilities: Risk reduced (Critical/High to Medium/Low, depending on findings).

  • Currently Implemented:

    • None.

  • Missing Implementation:

    • Fuzz testing of Hermes internals.
    • Use of memory safety tools during Hermes build.
    • Regular updates of Hermes engine.