Skip to content

Latest commit

 

History

History
89 lines (70 loc) · 4.89 KB

mitigations.md

File metadata and controls

89 lines (70 loc) · 4.89 KB

Mitigation Strategies Analysis for catchorg/catch2

Mitigation Strategy: Conditional Compilation with Catch2

  • Description:

    1. Define a Preprocessor Macro: Choose a clear preprocessor macro (e.g., TESTING, CATCH2_ENABLED).
    2. Wrap Catch2 Includes: Use #ifdef and #endif to conditionally include all Catch2 headers: 
      #ifdef TESTING
#include <catch2/catch_all.hpp> // Or individual headers
#endif
    3. Wrap Test Case Definitions: Wrap all test case definitions and related Catch2 macros: 
      #ifdef TESTING
TEST_CASE("My Test", "[mytag]") {
    // ... test code ...
}
#endif
    4. Wrap Custom Reporters/Listeners: If you have custom reporters or event listeners, wrap their definitions and usage within the #ifdef blocks as well.
    5. Build System Integration: Ensure your build system (CMake, Make, etc.) defines the chosen macro only for test builds.

  • Threats Mitigated:

    • Inclusion in Production Builds (Severity: High): Prevents Catch2 code from being included in production releases.

  • Impact:

    • Inclusion in Production Builds: Risk reduced from High to Negligible (if implemented correctly).

  • Currently Implemented:

    • #ifdef TESTING is used to wrap most Catch2 code.
    • CMake is configured to define TESTING only for test targets.

  • Missing Implementation:

    • Some helper functions used in tests are not wrapped in #ifdef TESTING.

Mitigation Strategy: Catch2 Test Timeouts

  • Description:

    1. Identify Long-Running Tests: Identify tests or test sections that are known to take a significant amount of time.
    2. Apply .timeout() Modifier: Use the .timeout(seconds) modifier on TEST_CASE or SECTION blocks to set a time limit: 
      TEST_CASE("My Long Test", "[long]") {
  SECTION("Potentially Slow Operation") {
    REQUIRE(some_long_function() == expected);
  }
  .timeout(10); // Timeout after 10 seconds
}
    3. Granular Timeouts: Use nested SECTION blocks with different timeouts to pinpoint the specific part of a test that is causing delays.
    4. Review and Adjust: Regularly review and adjust timeout values as your code and tests evolve.

  • Threats Mitigated:

    • Denial of Service on Testing Infrastructure (Severity: Medium): Prevents tests from running indefinitely.
    • Hanging Tests (Severity: Low): Helps identify and diagnose stuck tests.

  • Impact:

    • Denial of Service: Risk reduced from Medium to Low.
    • Hanging Tests: Risk reduced from Low to Negligible.

  • Currently Implemented:

    • Some test cases have timeouts set using .timeout().

  • Missing Implementation:

    • Timeouts are not consistently applied across all test cases.

Mitigation Strategy: Review and Configure Catch2 Output (Redaction)

  • Description:

    1. Identify Sensitive Output: Determine if any test cases might print sensitive information to the console or to Catch2's output files (e.g., XML, JUnit).
    2. Custom Reporters (If Necessary): If standard output redaction isn't sufficient, create a custom Catch2 reporter. This allows you to intercept and modify the output before it's written. This is more complex but provides fine-grained control.
      • Inherit from Catch::StreamingReporterBase (or a more specific reporter class).
      • Override relevant methods (e.g., testCaseEnded, sectionEnded) to filter or redact sensitive data.
      • Register your custom reporter using CATCH_REGISTER_REPORTER.
    3. Command-Line Options: Explore Catch2's command-line options for controlling output verbosity and format. Options like -v (verbosity) and -r (reporter) can be used to limit the amount of information displayed.
    4. Filtering Test Output: If sensitive data is unavoidable in some output, consider using tools like grep or sed to filter the output after the tests have run, removing sensitive lines before storing or displaying the results. This is a less robust solution than a custom reporter.

  • Threats Mitigated:

    • Sensitive Information Leakage During Testing (Severity: Medium): Prevents sensitive data from being exposed in test output.

  • Impact:

    • Sensitive Information Leakage: Risk reduced from Medium to Low (depending on the effectiveness of redaction).

  • Currently Implemented:

    • None.

  • Missing Implementation:

    • No output redaction or custom reporters are in place. This is a significant gap if tests might handle sensitive data.