Skip to content

Latest commit

 

History

History
96 lines (76 loc) · 8.21 KB

mitigations.md

File metadata and controls

96 lines (76 loc) · 8.21 KB

Mitigation Strategies Analysis for dmlc/gluon-cv

Mitigation Strategy: Verified Model Loading with GluonCV API

Description:

  1. Trusted Source: Use only models from the official GluonCV Model Zoo (gluoncv.model_zoo) or a pre-approved, secured internal repository that mirrors the Model Zoo's structure and provides checksums.
  2. Checksum Verification (Integrated): Instead of manual checksum calculation, leverage gluon-cv's (potential, future) built-in mechanisms for checksum verification, if and when they become available. This would ideally be part of the gluoncv.model_zoo.get_model function or a related utility. Until then, continue with the manual checksum verification described previously, but design your code to be easily adaptable to a future GluonCV-provided solution.
  3. Pre-trained Model Loading: Use gluoncv.model_zoo.get_model(model_name, pretrained=True, root=...) to load pre-trained models. The root parameter should point to a secure, local directory where downloaded models are stored. Do not load models directly from the internet on every run.
  4. Error Handling: Wrap the model loading call in a try-except block to handle potential errors, such as:
    • FileNotFoundError: If the model file is not found.
    • RuntimeError: If there's an issue loading the model (e.g., checksum mismatch, corrupted file).
    • Other exceptions specific to the underlying framework (MXNet/PyTorch). In the except block, log the error, prevent further processing, and enter a safe state.

  • Threats Mitigated:

    • Malicious Model Substitution (Severity: Critical): Loading a backdoored model.
    • Model Tampering (Severity: High): Using a modified, potentially harmful model.
    • Untrusted Model Source (Severity: High): Using models from unverified locations.

  • Impact:

    • Malicious Model Substitution: Risk reduced to Very Low (assuming GluonCV's future checksum verification is robust).
    • Model Tampering: Risk reduced to Low.
    • Untrusted Model Source: Risk mitigated by policy (using only trusted sources) and enforced by the loading mechanism.

  • Currently Implemented:

    • gluoncv.model_zoo.get_model is used for loading pre-trained models.
    • The root parameter is set to a local directory.
    • Basic try-except error handling is in place.
    • Manual checksum verification (as described previously) is implemented outside of the gluon-cv API calls.

  • Missing Implementation:

    • Reliance on a future, hypothetical GluonCV-provided checksum verification feature. The current implementation uses a manual workaround.
    • More comprehensive error handling, specifically checking for RuntimeError and other potential exceptions during model loading.

Mitigation Strategy: GluonCV-Specific Input Preprocessing and Validation

Description:

  1. Use GluonCV Transforms: Always use the gluoncv.data.transforms module (and specifically, the presets submodules like gluoncv.data.transforms.presets.yolo, gluoncv.data.transforms.presets.ssd, etc.) to preprocess input data. These transforms are designed to handle the specific input requirements of each model in the Model Zoo. Do not implement custom preprocessing logic unless absolutely necessary and thoroughly vetted.
  2. Preset Selection: Choose the correct preset transform based on the model you are using. The GluonCV documentation clearly indicates which preset to use with each model.
  3. Input Type Handling: Ensure your input data (images, videos) is in the correct format (e.g., NumPy array, MXNet NDArray, PyTorch Tensor) before passing it to the GluonCV transforms. The transforms expect specific input types.
  4. Validation Before Transform: Before applying the GluonCV transforms, perform basic validation:
    • Check that the input is a valid image or video (using libraries like Pillow or OpenCV, but before any GluonCV-specific code).
    • Check the data type and dimensions (using NumPy or the underlying framework's functions).
  5. Validation After Transform (Optional, but Recommended): After applying the GluonCV transforms, you can optionally perform additional checks:
    • Verify that the transformed data has the expected shape and data type. This can help catch subtle errors in your input or in the transform application.
  6. Error Handling: Wrap the preprocessing and transform calls in try-except blocks to handle potential errors.

  • Threats Mitigated:

    • Adversarial Input (Severity: Medium): Subtly crafted inputs designed to cause misclassification.
    • Unexpected Model Behavior (Severity: Low): Input that doesn't match the model's expectations.
    • Preprocessing Vulnerabilities (Severity: Medium): Exploiting vulnerabilities in custom preprocessing code.

  • Impact:

    • Adversarial Input: Risk reduced to Low-Medium. Using the correct presets makes it harder to craft effective adversarial examples.
    • Unexpected Model Behavior: Risk reduced to Very Low.
    • Preprocessing Vulnerabilities: Risk reduced to Very Low by relying on GluonCV's well-tested transforms.

  • Currently Implemented:

    • gluoncv.data.transforms.presets.yolo.transform_test is used for preprocessing.
    • Basic input type checking (NumPy array) is performed before the transform.

  • Missing Implementation:

    • No validation after applying the GluonCV transform.
    • The validation logic is not consistently applied across all input endpoints.
    • No comprehensive error handling around the transform calls.

Mitigation Strategy: Safe Handling of GluonCV Outputs

Description:

  1. Output Type Awareness: Understand the data types and structures returned by the GluonCV model's forward pass (or equivalent inference method). This will typically be MXNet NDArrays or PyTorch Tensors.
  2. Bounds Checking: If the model output represents bounding boxes, class probabilities, or other numerical values, perform bounds checking to ensure the values are within expected ranges. For example:
    • Bounding box coordinates should be within the image dimensions.
    • Class probabilities should be between 0 and 1.
  3. Data Type Conversion (Careful): If you need to convert the output data to a different format (e.g., from float32 to int), do so carefully, handling potential overflow or underflow issues.
  4. Sanitization (If Displaying/Storing): If you are displaying the model's output (e.g., drawing bounding boxes on an image) or storing it in a database, sanitize the output to prevent potential injection vulnerabilities (e.g., cross-site scripting if displaying results in a web application). This is less directly related to GluonCV, but important for the overall application security.
  5. Error Handling: Handle potential errors during output processing (e.g., unexpected data types, out-of-bounds values).

  • Threats Mitigated:

    • Unexpected Model Output (Severity: Low): The model might produce unexpected output due to internal errors or adversarial input.
    • Data Type Errors (Severity: Low): Incorrect handling of data types can lead to crashes or unexpected behavior.
    • Injection Vulnerabilities (Severity: Medium to High): If the output is used in other parts of the application without proper sanitization.

  • Impact:

    • Unexpected Model Output: Risk reduced to Very Low with bounds checking.
    • Data Type Errors: Risk reduced to Very Low with careful data type handling.
    • Injection Vulnerabilities: Risk depends on the specific vulnerability and how the output is used, but sanitization is crucial.

  • Currently Implemented:

    • Basic conversion of model output to NumPy arrays.

  • Missing Implementation:

    • No bounds checking on bounding box coordinates or class probabilities.
    • No sanitization of output before displaying it (assuming the application has a visualization component).
    • No error handling during output processing.