Skip to content

Latest commit

 

History

History
57 lines (48 loc) · 6.01 KB

threat-modeling.md

File metadata and controls

57 lines (48 loc) · 6.01 KB

Threat Model Analysis for rsyslog/liblognorm

Threat: Denial of Service via Crafted Rulebase (CPU Exhaustion)

  • Description: An attacker submits a maliciously crafted rulebase that, when parsed or used for normalization by liblognorm, causes excessive CPU consumption. This leverages vulnerabilities or inefficiencies in liblognorm's rulebase parsing logic or the underlying regular expression engine (e.g., triggering catastrophic backtracking). The attacker's goal is to make the application unresponsive by exhausting CPU resources.
    • Impact: Application unavailability; denial of service.
    • Affected liblognorm Component:
      • liblognorm parser (functions related to loading and parsing rulebases, e.g., ln_load_ruleset, ln_parse_rule).
      • Regular expression engine used by liblognorm.
      • Normalization engine (functions that apply the rules, e.g., ln_normalize).
    • Risk Severity: High
    • Mitigation Strategies:
      • Strict Rulebase Validation: Implement robust validation before passing the rulebase to liblognorm. This includes checks for excessive complexity, known-bad regex patterns, and limits on rule count and size. This is crucial to prevent the application from even attempting to load a malicious rulebase.
      • Resource Limits: Use OS-level mechanisms (e.g., ulimit, cgroups) to limit the CPU time that liblognorm can consume.
      • Sandboxing: Execute liblognorm's parsing and normalization in a separate, sandboxed process with restricted privileges and resources.
      • Regular Expression Engine Hardening: If possible, configure liblognorm to use a regular expression engine that is resistant to catastrophic backtracking (e.g., RE2). Investigate liblognorm's configuration options for regex engine selection.

Threat: Denial of Service via Crafted Rulebase (Memory Exhaustion)

  • Description: An attacker provides a crafted rulebase that, when processed by liblognorm, causes excessive memory allocation, leading to an out-of-memory condition. This exploits vulnerabilities in how liblognorm handles rulebase parsing and internal data structure creation.
    • Impact: Application crash or unavailability due to out-of-memory errors; denial of service.
    • Affected liblognorm Component:
      • liblognorm parser (functions related to loading and parsing rulebases).
      • Memory allocation functions within liblognorm (internal functions responsible for allocating memory for rule representations).
      • Normalization engine.
    • Risk Severity: High
    • Mitigation Strategies:
      • Strict Rulebase Validation: (Same as for CPU exhaustion, with a focus on limiting constructs that could lead to large memory allocations).
      • Resource Limits: Use OS-level mechanisms (e.g., ulimit, cgroups) to limit the memory that liblognorm can consume.
      • Sandboxing: (Same as for CPU exhaustion).
      • Memory Usage Monitoring: Monitor liblognorm's memory usage during rulebase loading and normalization; trigger alerts if it exceeds thresholds.

Threat: Security Bypass due to Incorrect Normalization (liblognorm Bug)

  • Description: A bug within liblognorm's normalization logic causes it to incorrectly normalize a log message, even with a correctly written rulebase. This incorrect normalization leads a security system (relying on the normalized output) to fail to detect malicious activity. This is distinct from a rulebase error; the bug is in liblognorm itself.
    • Impact: Security bypass; attacker activity goes undetected.
    • Affected liblognorm Component:
      • Normalization engine (ln_normalize and related functions).
    • Risk Severity: High
    • Mitigation Strategies:
      • Liblognorm Updates: Keep liblognorm updated to the latest version to benefit from bug fixes and security patches. This is the primary mitigation for bugs within the library itself.
      • Redundant Security Checks: Do not rely solely on liblognorm's output for critical security decisions. Implement independent validation and checks.
      • Output Validation: After normalization, validate the output to ensure it conforms to expected data types and constraints. This can help detect some incorrect normalization cases.
      • Fuzz Testing of liblognorm: Contribute to the security of liblognorm by fuzz testing it with a wide range of inputs to identify potential bugs.

Threat: Code Injection (Highly Unlikely)

  • Description: A severe vulnerability (e.g., buffer overflow, format string vulnerability) within liblognorm's code allows an attacker to inject and execute arbitrary code by providing a crafted rulebase or log message. This is a direct vulnerability in liblognorm.
    • Impact: Complete system compromise; attacker gains full control.
    • Affected liblognorm Component: Potentially any part of liblognorm that handles input (parsing, normalization, regular expression processing).
    • Risk Severity: Critical (but extremely low likelihood)
    • Mitigation Strategies:
      • Liblognorm Updates: Keep liblognorm updated to the latest version. This is the most important mitigation.
      • Sandboxing: Running liblognorm in a sandboxed environment with minimal privileges significantly reduces the impact of a successful code injection.
      • Compiler Hardening: Compile the application and liblognorm with all available compiler security features (stack canaries, ASLR, DEP/NX).
      • Code Audit: For extremely high-security applications, consider a professional security audit of the liblognorm codebase.