Skip to content

Latest commit

 

History

History
112 lines (87 loc) · 10.3 KB

mitigations.md

File metadata and controls

112 lines (87 loc) · 10.3 KB

Mitigation Strategies Analysis for protocolbuffers/protobuf

Mitigation Strategy: Enforce Message Size and Depth Limits (Protobuf Parsing)

  • Description:

    1. Identify Maximums: Determine reasonable maximums for message size (bytes) and nesting depth, based on legitimate use cases.
    2. Configure Protobuf Parser: Use the protobuf library's configuration options to enforce these limits during parsing. This is crucial; it's not sufficient to check the size after the message has been fully parsed. Examples:
      • C++: CodedInputStream::SetTotalBytesLimit() and CodedInputStream::SetRecursionLimit().
      • Java: CodedInputStream.setSizeLimit() and similar methods.
      • Python: google.protobuf.message.SetRecursionLimit().
    3. Handle Limit Violations (Protobuf Error): The protobuf parser will return a specific error (e.g., a DecodeError in Python, an exception in C++/Java) when a limit is exceeded. Your code must catch this protobuf-specific error and handle it gracefully (reject, log, respond).
    4. Limit Repeated Fields (During Parsing): Within your parsing loop, while processing a repeated field, check the number of elements against a predefined maximum. This is done in conjunction with the overall message size limit.
    5. Test with Protobuf: Generate test messages (using protobuf) that are near, at, and above your limits to verify the parser's behavior.

  • Threats Mitigated:

    • Oversized Message DoS (Severity: High): Prevents attackers from sending huge messages that exhaust server resources during protobuf parsing.
    • Protobuf Bomb DoS (Severity: High): Prevents deeply nested messages from causing stack overflows or excessive memory allocation during protobuf parsing.
    • Resource Exhaustion (Severity: High): Reduces the risk of resource exhaustion attacks specifically targeting the protobuf parsing stage.

  • Impact:

    • Oversized Message DoS: Risk significantly reduced (High to Low).
    • Protobuf Bomb DoS: Risk significantly reduced (High to Low).
    • Resource Exhaustion: Risk reduced (High to Medium/Low).

  • Currently Implemented: [ Example: Implemented in ProtobufMessageHandler::parseMessage using CodedInputStream limits. Limits are 1MB and 50 levels. ] <-- YOU FILL THIS IN

  • Missing Implementation: [ Example: Repeated field limits are not enforced during parsing in src/legacy_parser.cc. ] <-- YOU FILL THIS IN

Mitigation Strategy: Keep Protobuf Libraries Updated and Fuzz Test (Protobuf Parser)

  • Description:

    1. Update Protobuf Components: Regularly update both the protobuf compiler (protoc) and the runtime libraries used in your application (C++, Java, Python, etc.). These are distinct components, and both need to be kept current.
    2. Protobuf Security Advisories: Subscribe to security advisories specifically for the protobuf project (e.g., the GitHub repository, mailing lists).
    3. Fuzz Protobuf Parser: Integrate fuzz testing that specifically targets the protobuf parsing functionality. The fuzzer should generate binary protobuf data (not text-based .proto files).
    4. Fuzz Target (Protobuf Input): Your fuzz target should take a raw byte array as input and attempt to parse it as a protobuf message using the protobuf library's parsing functions.
    5. Continuous Fuzzing (Protobuf): Ideally, use a platform like OSS-Fuzz for continuous fuzzing of the protobuf parser.
    6. Triage Protobuf Crashes: Prioritize and fix any crashes or errors reported by the fuzzer that occur within the protobuf library itself.

  • Threats Mitigated:

    • Parser Vulnerabilities (Severity: High/Critical): Reduces the risk of exploiting vulnerabilities in the protobuf parser implementation.
    • Code Execution (Severity: Critical): Helps prevent vulnerabilities in the protobuf parser that could lead to arbitrary code execution.
    • Information Disclosure (Severity: Medium/High): Helps prevent vulnerabilities in the protobuf parser that could leak information.

  • Impact:

    • Parser Vulnerabilities: Risk significantly reduced (High/Critical to Low/Medium).
    • Code Execution: Risk significantly reduced (Critical to Low).
    • Information Disclosure: Risk reduced (Medium/High to Low/Medium).

  • Currently Implemented: [ Example: Protobuf library is updated monthly. Fuzz testing is implemented using libprotobuf-mutator and integrated into the CI pipeline. ] <-- YOU FILL THIS IN

  • Missing Implementation: [ Example: Continuous fuzzing with OSS-Fuzz is not yet set up. Fuzzing only covers a subset of message types. ] <-- YOU FILL THIS IN

Mitigation Strategy: Strict Unknown Field Handling (Protobuf Schema)

  • Description:

    1. Choose a Protobuf Strategy: Decide how your application will handle "unknown fields" (fields present in the serialized data but not defined in the current .proto schema):
      • Reject (Recommended): Configure the protobuf parser to reject any message containing unknown fields. This is the most secure option.
      • Log: Log the presence and content of unknown fields.
      • Ignore (with extreme caution): Only if you are absolutely certain your code never interacts with unknown fields.
    2. Protobuf Parser Configuration: Use the protobuf library's configuration options to enforce your chosen strategy. This is a setting within the protobuf parsing API. Examples:
      • C++: Use FailoverInputStream and set_require_parse_success(true) to reject.
      • Java: Use JsonFormat.Parser.ignoringUnknownFields() (for JSON format) or similar options for binary format.
      • Python: The default behavior is to preserve unknown fields, but you can iterate over _unknown_fields and raise an exception.
    3. Schema Evolution (Protobuf): Follow strict .proto schema evolution best practices:
      • Never Reuse Field Numbers: This is a fundamental rule of protobuf schema evolution.
      • Use reserved: When removing fields, mark their field numbers and names as reserved in the .proto file. This prevents accidental reuse.
    4. Test with Protobuf: Generate test messages (using protobuf) that include unknown fields to verify your parser's behavior.

  • Threats Mitigated:

    • Data Injection via Unknown Fields (Severity: Medium/High): Prevents attackers from injecting malicious data into unknown fields that might be inadvertently processed. This is a protobuf-specific threat.
    • Logic Bugs (Severity: Medium): Reduces the risk of unexpected behavior caused by unknown fields interacting with application logic.
    • Compatibility Issues (Severity: Low/Medium): Helps maintain compatibility between different versions of your application using protobuf.

  • Impact:

    • Data Injection: Risk significantly reduced (Medium/High to Low, if rejecting).
    • Logic Bugs: Risk reduced (Medium to Low).
    • Compatibility Issues: Risk reduced (Low/Medium to Low).

  • Currently Implemented: [ Example: The application currently ignores unknown fields. The .proto files use the reserved keyword correctly. ] <-- YOU FILL THIS IN

  • Missing Implementation: [ Example: The application should be configured to reject messages with unknown fields. This requires changes to the protobuf parsing logic. ] <-- YOU FILL THIS IN

Mitigation Strategy: Input Validation and Overflow Checks (Post-Protobuf Parsing)

  • Description:

    1. Post-Parsing Validation: After successfully parsing a protobuf message using the protobuf library, implement additional validation logic. The .proto schema is not sufficient for full validation.
    2. Data Type Checks: Verify that values are within the expected range for their protobuf data type (e.g., a uint32 is actually non-negative).
    3. Overflow Checks (After Protobuf Decode): For integer fields, perform explicit overflow checks after the protobuf library has decoded the value. The variable-length encoding of protobuf integers can lead to subtle overflow issues if not handled carefully. 
      // Example: Checking for overflow with a uint64_t from protobuf
uint64_t value = my_message.some_uint64_field();
if (value > MAX_ALLOWED_VALUE) { // MAX_ALLOWED_VALUE is your application-specific limit
    // Handle the overflow
}
    4. Business Rules: Enforce application-specific business rules that go beyond the basic data types defined in the .proto file.
    5. Test with Valid and Invalid Protobuf: Test your validation logic with both valid and invalid protobuf messages (generated using protobuf) to ensure it catches all expected errors.

  • Threats Mitigated:

    • Integer Overflow (Severity: High): Prevents attackers from exploiting integer overflow vulnerabilities after protobuf decoding.
    • Logic Bugs (Severity: Medium/High): Reduces the risk of unexpected behavior caused by invalid data that is structurally valid according to the .proto schema.
    • Data Corruption (Severity: Medium/High): Prevents invalid data from being stored or processed after it has been parsed by the protobuf library.

  • Impact:

    • Integer Overflow: Risk significantly reduced (High to Low).
    • Logic Bugs: Risk reduced (Medium/High to Low/Medium).
    • Data Corruption: Risk reduced (Medium/High to Low/Medium).

  • Currently Implemented: [ Example: Basic range checks are performed on some integer fields after protobuf parsing, but not all. Overflow checks are inconsistent. ] <-- YOU FILL THIS IN

  • Missing Implementation: [ Example: Comprehensive input validation and overflow checks need to be implemented for all message fields after protobuf parsing, especially in the financial transaction module. ] <-- YOU FILL THIS IN