Skip to content

Latest commit

 

History

History
60 lines (47 loc) · 7.61 KB

threat-modeling.md

File metadata and controls

60 lines (47 loc) · 7.61 KB

Threat Model Analysis for doctrine/lexer

Threat: Regular Expression Denial of Service (ReDoS)

  • Threat: Regular Expression Denial of Service (ReDoS)

    • Description: An attacker crafts a malicious input string that exploits a poorly written regular expression within the lexer's rules. The attacker's input triggers catastrophic backtracking in the regular expression engine, causing the lexer (and potentially the entire application) to consume excessive CPU time and become unresponsive. The attacker doesn't need to know the specific regex, but can use fuzzing or known ReDoS patterns to find vulnerabilities.
    • Impact: Denial of Service (DoS). The application becomes unavailable to legitimate users. Depending on the application's architecture, this could range from a single thread/process being affected to a complete system outage.
    • Affected Lexer Component: The match() method within the AbstractLexer class (and its implementations in concrete lexer classes). Specifically, the regular expressions defined in the getCatchablePatterns() and getNonCatchablePatterns() methods (or their equivalents in custom lexer implementations) are the vulnerable points.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Regex Review and Testing: Thoroughly review all regular expressions for potential ReDoS vulnerabilities. Use tools like regex101.com (with the PCRE flavor) and specialized ReDoS checkers to analyze the regexes. Prioritize simple, well-defined regexes.
      • Safe Regex Libraries/Alternatives: Consider using regular expression libraries or alternatives that are designed to be resistant to ReDoS. Some libraries have built-in backtracking limits or use algorithms that avoid catastrophic backtracking.
      • Input Validation (Pre-Lexing): Implement strict input validation before the input reaches the lexer. Limit the length and character set of the input to reduce the search space for the regular expressions. This is a defense-in-depth measure.
      • Resource Limits: Set resource limits (CPU time, memory) on the process or thread running the lexer. This can prevent a single ReDoS attack from consuming all system resources.
      • Timeouts: Implement a timeout mechanism for the lexer's match() operation. If the lexer takes longer than a predefined threshold, terminate it and return an error.
      • Monitoring: Monitor the lexer's performance in production to detect unusually long processing times, which could indicate a ReDoS attack.

Threat: Excessive Token Generation

  • Threat: Excessive Token Generation

    • Description: An attacker provides input that, while not causing ReDoS, results in the lexer generating an extremely large number of tokens. The attacker might exploit ambiguities or repetitions in the grammar to create input that produces a disproportionately large token stream.
    • Impact: Denial of Service (DoS). Downstream components that process the token stream may become overwhelmed, leading to memory exhaustion, slow performance, or crashes. While the impact is on downstream components, the root cause is the lexer's handling of the input, making it a direct threat to the lexer's intended operation.
    • Affected Lexer Component: The main lexing loop within the AbstractLexer's scan() or tokenize() methods (depending on the specific lexer implementation). The logic that iterates through the input and generates tokens is the affected area.
    • Risk Severity: High
    • Mitigation Strategies:
      • Token Limit: Implement a hard limit on the maximum number of tokens the lexer is allowed to generate for a single input. Reject input that exceeds this limit.
      • Input Size Limit: Enforce a reasonable maximum length for the input string. This indirectly limits the potential number of tokens.
      • Grammar Review: Carefully review the grammar or language definition being parsed to identify potential sources of excessive token generation. Simplify the grammar where possible.
      • Streaming/Chunking (Downstream): While primarily a downstream concern, designing for this helps mitigate the impact of the lexer generating many tokens.

Threat: Infinite Loop in Lexer

  • Threat: Infinite Loop in Lexer

    • Description: A bug in the lexer's logic, potentially triggered by a specific, unusual input, causes the lexer to enter an infinite loop. This could be due to incorrect handling of edge cases, errors in the state transitions, or flaws in the regular expressions (even if not ReDoS).
    • Impact: Denial of Service (DoS). The lexer consumes CPU indefinitely, preventing further processing and potentially affecting the entire application.
    • Affected Lexer Component: The main lexing loop within the AbstractLexer's scan() or tokenize() methods. The logic that determines the next state and token is the potential source of the infinite loop.
    • Risk Severity: High
    • Mitigation Strategies:
      • Thorough Testing: Extensively test the lexer with a wide variety of inputs, including edge cases, invalid inputs, and boundary conditions. Use fuzzing techniques to generate random and unexpected inputs.
      • Code Reviews: Conduct thorough code reviews of the lexer implementation, paying close attention to the loop conditions and state transitions.
      • Timeouts: Implement a timeout mechanism for the entire lexing process. If the lexer takes longer than a predefined threshold, terminate it and report an error.
      • Defensive Programming: Include checks within the lexing loop to detect potential infinite loop conditions (e.g., checking if the lexer's position is advancing).

Threat: Lexer Definition Tampering

  • Threat: Lexer Definition Tampering

    • Description: An attacker gains unauthorized access to the application's code or configuration and modifies the lexer's definition (e.g., the regular expressions or token types). This allows the attacker to change how input is parsed, potentially introducing vulnerabilities or bypassing security checks.
    • Impact: Varies widely, potentially leading to code execution, data breaches, or other severe consequences, depending on how the modified lexer is used. This is a direct threat because the lexer's core functionality is compromised.
    • Affected Lexer Component: The files or data structures that define the lexer's rules (e.g., the class extending AbstractLexer, configuration files, or database entries that store the lexer definition).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Access Control: Strictly control access to the lexer definition files and data. Use appropriate file system permissions, database security measures, and access control lists.
      • Integrity Checks: Implement integrity checks (e.g., checksums, digital signatures, or hash comparisons) to verify that the lexer definition has not been tampered with. These checks should be performed before the lexer is used.
      • Secure Deployment: Use secure deployment practices to prevent unauthorized modification of the application's code and configuration during deployment.
      • Code Reviews: Treat the lexer definition as code and subject it to the same security practices as other code, including code reviews and security audits.