Skip to content

Latest commit

 

History

History
96 lines (77 loc) · 7.86 KB

mitigations.md

File metadata and controls

96 lines (77 loc) · 7.86 KB

Mitigation Strategies Analysis for academysoftwarefoundation/openvdb

Mitigation Strategy: Strict File Format Pre-Validation (OpenVDB-Assisted)

Description:

  1. Identify Entry Points: Determine all points where VDB files are loaded.
  2. Use OpenVDB's openvdb::io::File (with Caution): Instead of a completely separate pre-parser, leverage OpenVDB's openvdb::io::File class but in a very limited way. The goal is to use OpenVDB's own initial checks, but without fully loading the grid.
  3. Open in Read-Only Mode: Open the file using openvdb::io::File::open() in read-only mode.
  4. Header and Metadata Checks:
    • Immediately after opening, do not call openvdb::io::File::readGrid().
    • Instead, use openvdb::io::File::getMetadata() to retrieve only the file-level metadata.
    • Inspect the metadata:
      • Verify the file version.
      • Check grid names and types.
      • Examine grid bounding boxes (if available in metadata) for reasonable sizes.
      • Validate any custom metadata you expect.
    • Use file.hasGrid("gridName") to check for expected grids without loading them.
  5. Early Rejection: If any of these metadata checks fail, close the file (file.close()) and reject it without attempting to read any grid data.
  6. Limited readGridMetadata() (Optional): If absolutely necessary, you can use openvdb::io::File::readGridMetadata() to read metadata for specific grids without loading the voxel data. However, be extremely cautious with this, as it delves deeper into OpenVDB's parsing. Prefer file-level metadata checks whenever possible.
  7. Proceed with Caution: Only if all preliminary checks pass, proceed to load the grid data using openvdb::io::File::readGrid().

  • Threats Mitigated:

    • Maliciously Crafted VDB Files (Severity: High): Reduces the risk of exploiting vulnerabilities in the full grid loading process by performing early checks.
    • Data Corruption (Severity: Medium): Helps detect corrupted files before loading potentially harmful data.
    • Some Denial-of-Service (DoS) Attacks (Severity: Medium): Can prevent some DoS attacks based on invalid metadata or excessively large reported grid sizes.

  • Impact:

    • Maliciously Crafted Files: Moderately reduces risk. Better than no pre-validation, but not as strong as a completely separate pre-parser.
    • Data Corruption: Moderately reduces risk.
    • DoS: Partially reduces risk.

  • Currently Implemented: (Example: Using openvdb::io::File, but not performing these specific metadata checks before readGrid().)

  • Missing Implementation: (Example: Need to modify file loading logic to perform metadata checks before calling readGrid().)

Mitigation Strategy: Data Range and Metadata Validation (Post-Loading, OpenVDB-Specific)

Description:

  1. Define Expected Ranges: For each OpenVDB grid type and data type (e.g., openvdb::FloatGrid, openvdb::Vec3fGrid, openvdb::Int32Grid) used in your application, define the expected and safe ranges of values.
  2. Post-Loading Checks (Iterators): Immediately after loading a grid using openvdb::io::File::readGrid() or creating a new grid, use OpenVDB's iterators (e.g., GridType::ValueOnCIter, GridType::ValueAccessor) to access voxel values. Do not use raw pointer access.
  3. Range Enforcement (Within Iteration): Within the iterator loop:
    • Use the iterator's getValue() method to retrieve the voxel value.
    • Check if the value falls within the predefined safe range for that grid type.
    • If out of range:
      • Log an error.
      • Take appropriate action (reject, clamp, replace with default).
  4. Metadata Validation (OpenVDB API):
    • Use grid->getMetadata() to retrieve metadata associated with the grid.
    • Iterate through the metadata (using openvdb::MetaMap::begin(), end(), and iterators).
    • For each metadata entry:
      • Check its type using metadata->typeName().
      • Cast to the appropriate type (e.g., openvdb::StringMetadata, openvdb::Int32Metadata) only after verifying the type.
      • Validate the value (e.g., string length, numerical range).
  5. Tree Structure Validation (Optional, Advanced): For advanced use cases, you might consider validating aspects of the OpenVDB tree structure itself (e.g., checking the depth of the tree, the number of nodes at certain levels). This is generally not necessary for most applications but can provide an extra layer of defense against highly sophisticated attacks. Use OpenVDB's tree traversal methods for this.

  • Threats Mitigated:

    • Data Corruption (Severity: Medium): Prevents corrupted or maliciously injected out-of-range values from causing issues.
    • Logic Errors (Severity: Low): Enforces expected data ranges.
    • Some Exploits (Severity: Medium): Can prevent exploits that rely on specific out-of-range values.

  • Impact:

    • Data Corruption: Significantly reduces risk.
    • Logic Errors: Reduces risk.
    • Exploits: Moderately reduces risk.

  • Currently Implemented: (Example: Accessing voxel data using iterators, but no range checks.)

  • Missing Implementation: (Example: Need to add range checks within the iterator loops in process_grid.cpp.)

Mitigation Strategy: Progressive Loading/Chunked Processing (Using OpenVDB's Capabilities)

Description:

  1. Workflow Analysis: Determine if your application can process VDB data in smaller, manageable chunks.
  2. Identify Chunk Boundaries: Define how to divide the VDB grid into chunks (e.g., spatial regions, specific tree levels).
  3. Use OpenVDB Iterators (Region-Based):
    • Use OpenVDB's iterators with bounding box constraints to access only a specific region of the grid at a time. For example, use GridType::cbeginValueOn(bbox) to iterate over active voxels within a bounding box.
    • Process each region separately.
  4. Use OpenVDB's copy with Bounding Boxes:
    • If you need to create a new grid containing only a portion of the original grid, use GridType::copy(otherGrid, bbox). This creates a new grid containing only the data within the specified bounding box.
  5. Use OpenVDB's Tree Pruning (Advanced):
    • For very large grids, consider using OpenVDB's tree pruning functions (e.g., openvdb::tools::prune() ) to remove unnecessary nodes from the tree, reducing memory usage. Be very careful with pruning, as it can alter the grid's data.
  6. Streaming (Advanced - openvdb::io::Stream): For extremely large datasets or real-time processing, explore OpenVDB's streaming capabilities (openvdb::io::Stream). This allows you to read and write VDB data incrementally, without loading the entire file into memory. This requires careful design and is more complex than other methods.
  7. Memory Management: Carefully manage the memory associated with each chunk. Release memory used by a chunk after it has been processed.

  • Threats Mitigated:

    • Denial-of-Service (DoS) Attacks (Severity: High): Reduces memory footprint and allows for early termination.
    • Data Corruption (Severity: Medium): Limits the impact of corruption to a specific chunk.

  • Impact:

    • DoS: Significantly reduces risk.
    • Data Corruption: Moderately reduces risk.

  • Currently Implemented: (Example: Not using chunked processing. Loading entire grids.)

  • Missing Implementation: (Example: Need to refactor render_volume() to use region-based iterators and process the grid in chunks.)