Skip to content

Latest commit

 

History

History
120 lines (89 loc) · 13.1 KB

mitigations.md

File metadata and controls

120 lines (89 loc) · 13.1 KB

Mitigation Strategies Analysis for google/sanitizers

Mitigation Strategy: Restrict Sanitizer Usage to Development and Testing Environments

  • Description:

    1. Define Production vs. Non-Production: Clearly differentiate between production environments (live, user-facing) and non-production environments (development, testing, staging).
    2. Disable Sanitizers in Production Builds: Configure the build system to automatically exclude sanitizer flags (e.g., -fsanitize=address) when building for production. This should be based on build configurations or environment variables.
    3. Enforce Production Build Verification: Implement checks in build or deployment processes to confirm that production binaries are compiled without sanitizer instrumentation.
    4. Developer Training: Educate developers on the performance implications of sanitizers and the importance of using sanitizer-disabled builds for production deployments.

    • Threats Mitigated:

      • Performance Degradation in Production (High Severity): Running applications with sanitizers in production introduces significant performance overhead, leading to slow response times, service disruptions, and potential denial of service.
      • Unexpected Behavior from Sanitizer Runtime in Production (Medium Severity): Interactions between the sanitizer runtime and production environments could lead to unforeseen application behavior or instability.

    • Impact:

      • Performance Degradation in Production: High Reduction. Eliminates the performance overhead of sanitizers in production, ensuring expected application performance.
      • Unexpected Behavior from Sanitizer Runtime in Production: Medium Reduction. Removes the risk of unexpected issues caused by the sanitizer runtime in production.

    • Currently Implemented:

      • Yes, in Build System (CMake): The project's CMake configuration disables sanitizers when building in Release mode, intended for production. This is controlled by the BUILD_TYPE variable.

    • Missing Implementation:

      • Deployment Script Verification: Deployment scripts do not currently explicitly verify that deployed binaries are sanitizer-free. Adding a check to confirm the absence of sanitizer instrumentation in production deployments would enhance security.

Mitigation Strategy: Utilize Build System Flags for Conditional Sanitizer Compilation

  • Description:

    1. Introduce Sanitizer Build Flags: Define dedicated build system flags or variables (e.g., ENABLE_ASAN, ENABLE_MSAN) to control the inclusion of specific sanitizers during compilation.
    2. Implement Conditional Logic: In the build system (CMake, Makefiles), use conditional statements to include sanitizer compiler and linker flags only when the corresponding build flags are enabled.
    3. Document Build Instructions: Provide clear documentation on how to use these build flags to enable or disable sanitizers for different build types (debug, test, release).
    4. IDE Integration (Optional): Consider providing IDE project configurations or scripts to simplify toggling sanitizer flags within development environments.

    • Threats Mitigated:

      • Accidental Sanitizer Inclusion in Production Builds (Medium Severity): Without clear flags, developers might unintentionally build production versions with sanitizers, leading to performance and stability issues.
      • Build System Complexity Related to Sanitizers (Low Severity): Managing sanitizer integration without dedicated flags can make the build system more complex and harder to maintain.

    • Impact:

      • Accidental Sanitizer Inclusion in Production Builds: Medium Reduction. Reduces the risk of accidental inclusion by providing a clear and controlled mechanism for enabling/disabling sanitizers.
      • Build System Complexity Related to Sanitizers: Low Reduction. Improves build system organization and maintainability by centralizing sanitizer control.

    • Currently Implemented:

      • Yes, in Build System (CMake): The project uses ENABLE_SANITIZERS CMake option to control sanitizer inclusion. Developers can use -DENABLE_SANITIZERS=ON/OFF during CMake configuration.

    • Missing Implementation:

      • IDE Project Configuration: Specific IDE project configurations for easily toggling sanitizer flags are not currently provided. Creating these would improve developer experience.

Mitigation Strategy: Implement CI/CD Pipeline Integration for Sanitizer-Enabled Builds

  • Description:

    1. Create Dedicated Sanitizer CI Jobs: Set up separate CI/CD pipeline jobs specifically designed to run tests with sanitizers enabled (e.g., "ASan Tests", "MSan Tests").
    2. Enable Sanitizers in CI Jobs: Configure these CI jobs to use the build system flags to enable the desired sanitizers during compilation and testing within the CI environment.
    3. Automated Test Execution with Sanitizers: Ensure that the CI pipeline automatically executes relevant tests (unit, integration) in these sanitizer-enabled jobs.
    4. Sanitizer Report Collection and Analysis: Configure the CI system to collect and analyze sanitizer output (logs, reports) from these jobs.
    5. CI Failure on Sanitizer Errors (Recommended): Configure the CI pipeline to fail if sanitizer-enabled tests report errors, preventing potentially vulnerable code from progressing further in the pipeline.

    • Threats Mitigated:

      • Undetected Memory Safety and Undefined Behavior Issues (High Severity): Without automated sanitizer testing, critical memory safety and undefined behavior bugs might remain undetected until production, leading to vulnerabilities and crashes.
      • Delayed Bug Detection (Medium Severity): Manual sanitizer testing is less frequent and comprehensive than automated CI integration, resulting in delayed bug detection and increased remediation costs.

    • Impact:

      • Undetected Memory Safety and Undefined Behavior Issues: High Reduction. Significantly reduces the risk of these issues reaching production by automating sanitizer testing.
      • Delayed Bug Detection: Medium Reduction. Enables earlier and more frequent bug detection, lowering development costs and improving code quality.

    • Currently Implemented:

      • Yes, in GitLab CI: The project's GitLab CI pipeline includes a "Sanitizer Tests" stage that runs tests with AddressSanitizer enabled. Sanitizer logs are collected as artifacts.

    • Missing Implementation:

      • MSan and UBSan CI Integration: Currently, only ASan is integrated into CI. Expanding to include MemorySanitizer (MSan) and UndefinedBehaviorSanitizer (UBSan) in CI would broaden the scope of automated sanitizer testing.
      • Automated Issue Tracking Integration: While logs are collected, there's no automated system to create issues in issue trackers (like Jira or GitHub Issues) directly from sanitizer findings in CI.

Mitigation Strategy: Utilize Sanitizer Suppression Mechanisms for Verified False Positives

  • Description:

    1. Investigate Sanitizer Reports: When sanitizers report errors, thoroughly investigate the code to determine if it's a genuine bug or a false positive.
    2. Verify False Positives: Confirm that a report is a false positive through code analysis, understanding sanitizer behavior, and consulting documentation if needed.
    3. Create Suppression Files: For verified false positives, create sanitizer suppression files (e.g., asan_suppressions.txt) containing rules to silence these specific reports. Rules typically use patterns to match function names or file paths.
    4. Apply Suppression Files to Sanitizer Runtime: Configure the sanitizer runtime to use these suppression files, usually via environment variables (e.g., ASAN_OPTIONS=suppressions=asan_suppressions.txt).
    5. Document Suppressions Clearly: Document each suppression rule in the file, explaining why it's a false positive and providing relevant context.
    6. Regularly Review Suppressions: Periodically review suppression files to ensure suppressions are still valid false positives and that rules are still accurate as the codebase evolves.

    • Threats Mitigated:

      • Developer Time Wasted on False Positives (Medium Severity): False positives consume developer time investigating non-issues, slowing down development.
      • Developer Desensitization to Sanitizer Reports (Low Severity): Frequent false positives can lead to developers ignoring or becoming less attentive to sanitizer reports, potentially missing real issues.

    • Impact:

      • Developer Time Wasted on False Positives: Medium Reduction. Reduces wasted time by silencing known false positives, allowing focus on genuine issues.
      • Developer Desensitization to Sanitizer Reports: Low Reduction. Helps maintain developer focus on real issues by reducing noise from false positives.

    • Currently Implemented:

      • Partially Implemented: The project has an asan_suppressions.txt file, but it's sparsely populated and lacks detailed documentation for existing suppressions.

    • Missing Implementation:

      • Comprehensive Suppression File Population: The suppression file needs to be expanded to include suppressions for all known and verified false positives encountered during testing.
      • Detailed Suppression Documentation: Each suppression rule should be documented with clear explanations.
      • Regular Suppression Review Process: A process for periodic review and update of the suppression file needs to be established as part of the development workflow.

Mitigation Strategy: Secure Logging and Error Handling for Sanitizer Output

  • Description:

    1. Isolate Sanitizer Logs: Configure logging to direct sanitizer output (error messages, reports) to separate log files or dedicated logging channels, distinct from general application logs.
    2. Restrict Access to Sanitizer Logs: Implement access controls to limit access to sanitizer logs to authorized personnel (developers, security team, CI/CD system). Prevent public exposure, especially in production.
    3. Prevent User Exposure of Sanitizer Output: Ensure sanitizer error messages are never directly displayed to end-users in production. Implement robust error handling to catch potential issues and present user-friendly error messages instead.
    4. Redact Sensitive Data in Public Logs (If Necessary): If sanitizer output must be shared externally (e.g., for bug reports), carefully redact any potentially sensitive information (memory addresses, internal paths) before sharing.

    • Threats Mitigated:

      • Information Leakage through Sanitizer Error Messages (Medium Severity): Sanitizer messages can reveal internal program details (memory addresses, function names, stack traces) exploitable by attackers if exposed in production or public logs.
      • Exposure of Internal Application Structure (Low Severity): Detailed sanitizer output can provide insights into the application's internal workings, potentially aiding reconnaissance by attackers.

    • Impact:

      • Information Leakage through Sanitizer Error Messages: Medium Reduction. Significantly reduces the risk of information leakage by isolating and controlling access to sanitizer output.
      • Exposure of Internal Application Structure: Low Reduction. Minimizes the risk of exposing internal details by controlling access to detailed sanitizer logs.

    • Currently Implemented:

      • Partially Implemented: Sanitizer output is logged to standard error, captured by CI/CD, and stored as artifacts with restricted access. However, dedicated sanitizer log separation is not fully implemented in all environments.

    • Missing Implementation:

      • Dedicated Sanitizer Log Channels/Files: Implement logging configuration to direct sanitizer output to separate, dedicated log destinations in all environments (development, staging, CI/CD).
      • Access Control for Local Logs: Consider stricter access control for log files in local development and staging to prevent accidental exposure of sanitizer output.
      • Production Error Handling for Sanitizer-Related Issues: Review and enhance production error handling to ensure that any sanitizer-related errors (should they occur in production despite mitigations) are gracefully handled without exposing raw sanitizer output to users.