Skip to content

Latest commit

 

History

History
102 lines (77 loc) · 6.25 KB

mitigations.md

File metadata and controls

102 lines (77 loc) · 6.25 KB

Mitigation Strategies Analysis for tencent/ncnn

Mitigation Strategy: Digital Signatures for Model Integrity (ncnn Loading Verification)

Description:

  1. Key Generation: (External, but prerequisite) Generate a cryptographic key pair.
  2. Signing: (External) Sign the .param and .bin files.
  3. Distribution: (External) Distribute signed files and signature.
  4. Embedding Public Key: (Can be external, but needs to be secure) Securely embed the public key.
  5. Verification (ncnn-Direct): Before calling ncnn::Net::load_param and ncnn::Net::load_model:
    • Read the model files (.param, .bin) and the signature files.
    • Use a cryptographic library (this could be a separate library, or potentially a future ncnn extension, but currently it's external logic before the ncnn calls) to verify the signature against the file contents using the embedded public key.
    • Only if verification is successful, proceed to call ncnn::Net::load_param and ncnn::Net::load_model with the verified file paths.
    • If verification fails, do not call the ncnn loading functions. Handle the error appropriately (log, alert, exit).

Threats Mitigated:

  • Model Tampering (High Severity): Ensures that the model loaded by ncnn is the authentic, untampered model.

Impact:

  • Model Tampering: Risk significantly reduced (nearly eliminated if key management is secure).

Currently Implemented: (Example - Replace with your project's status)

  • Signature verification logic implemented before calls to ncnn::Net::load_param and ncnn::Net::load_model in model_loader.cpp.

Missing Implementation: (Example - Replace with your project's status)

  • None (assuming external key management and signing are handled separately). The core ncnn-related part is the conditional loading based on verification.

Mitigation Strategy: Input Validation and Sanitization (Pre-ncnn Processing)

Description:

  1. Identify Input Types: Determine all data types passed to ncnn::Extractor::input.
  2. Define Valid Ranges: Define valid ranges, dimensions, and formats for each input type.
  3. Implement Checks (ncnn-Direct): Before calling ncnn::Extractor::input:
    • Implement strict checks to ensure the input data conforms to the defined valid ranges. This is code that executes before any ncnn API calls.
    • Use conditional statements to reject invalid input.
  4. Sanitization (Context-Dependent, Pre-ncnn): If necessary, sanitize the input data before passing it to ncnn.
  5. Error Handling: If validation fails, do not call ncnn::Extractor::input. Handle the error.

Threats Mitigated:

  • Buffer Overflows (High Severity): Prevents excessively large inputs from being passed to ncnn.
  • Integer Overflows (High Severity): Prevents invalid numerical values from being passed to ncnn.
  • Denial of Service (DoS) (Medium to High Severity): Reduces the risk of DoS attacks by rejecting malformed input.
  • Code Injection (High Severity): (Less likely with ncnn, but sanitization helps).
  • Logic Errors (Medium Severity): Prevents unexpected behavior due to invalid input.

Impact:

  • Buffer Overflows, Integer Overflows, Code Injection: Risk significantly reduced.
  • Denial of Service: Risk reduced.
  • Logic Errors: Risk reduced.

Currently Implemented: (Example)

  • Image dimension checks implemented before calling ncnn::Extractor::input in image_processor.cpp.

Missing Implementation: (Example)

  • Comprehensive validation for all input types (audio, text validation missing).
  • Sanitization for text input is missing.

Mitigation Strategy: Resource Exhaustion Protection (Timeouts for ncnn Operations)

Description:

  1. Input Size Limits: (Covered in Input Validation - Pre-ncnn).
  2. Timeouts (ncnn-Direct):
    • Before calling ncnn::Extractor::input and ncnn::Extractor::extract, start a timer (e.g., using std::chrono).
    • Set a reasonable timeout value.
    • After the ncnn::Extractor::extract call (or after both input and extract if measuring the total time), check if the elapsed time exceeds the timeout.
    • If the timeout is exceeded, handle the error appropriately. This does not involve directly interacting with ncnn to stop it (ncnn doesn't have built-in timeout mechanisms), but rather involves managing the control flow around the ncnn calls. You might need to consider thread management if ncnn is running in a separate thread.

Threats Mitigated:

  • Denial of Service (DoS) (Medium to High Severity): Prevents ncnn from running indefinitely due to malicious input or unexpected model behavior.

Impact:

  • Denial of Service: Risk significantly reduced.

Currently Implemented: (Example)

  • None.

Missing Implementation: (Example)

  • Timeouts are not implemented around calls to ncnn::Extractor::input and ncnn::Extractor::extract.

Mitigation Strategy: ncnn Library Updates

Description:

  1. Monitor for Updates: (External process) Regularly check for new ncnn releases.
  2. Review Release Notes: (External process) Check for security-related changes.
  3. Update (ncnn-Direct):
    • Replace the existing ncnn library files (headers, libraries) with the updated versions.
    • Rebuild the application, ensuring it links against the new ncnn library. This is the direct interaction with ncnn – replacing its files.
  4. Testing: (External, but crucial) Thoroughly test after updating.
  5. Dependency Management: (External, but helpful) Use a dependency manager.

Threats Mitigated:

  • Known Vulnerabilities (Severity Varies): Addresses vulnerabilities discovered and fixed in newer ncnn versions.

Impact:

  • Known Vulnerabilities: Risk reduced by staying up-to-date.

Currently Implemented: (Example)

  • Developers manually update ncnn files and rebuild.

Missing Implementation: (Example)

  • Automated update process.