Skip to content

Latest commit

 

History

History
39 lines (32 loc) · 3.77 KB

threat-modeling.md

File metadata and controls

39 lines (32 loc) · 3.77 KB

Threat Model Analysis for madler/zlib

Threat: Compression Bomb (Zip Bomb)

  • Description: An attacker crafts a small, highly-compressed file that expands to an extremely large size upon decompression. The attacker sends this to the application, aiming to exhaust server resources.
    • Impact: Denial of Service (DoS). Application becomes unresponsive or crashes due to resource exhaustion (memory, CPU, or disk space).
    • Affected zlib Component: inflate() function and related streaming API functions (inflateInit(), inflate(), inflateEnd()). The core decompression logic is exploited.
    • Risk Severity: High (can easily lead to DoS)
    • Mitigation Strategies:
      • Strict Output Size Limits: Implement a hard limit on decompressed data size before full decompression. Use the streaming API (inflate()) and check output size incrementally. Reject input exceeding the limit.
      • Input Size Limits: Set reasonable limits on compressed input size before decompression.
      • Resource Limits: Use OS-level resource limits (memory, CPU time, disk space).
      • Monitoring: Monitor resource usage during decompression; terminate if thresholds are exceeded.
      • Sandboxing: Consider decompressing in a separate process or sandbox.

Threat: Memory Corruption (Buffer Overflow/Over-read)

  • Description: An attacker provides malformed compressed data that exploits a vulnerability (buffer overflow/over-read) in zlib's code, leading to writing outside allocated buffers or reading from unintended memory. The attacker aims for arbitrary code execution.
    • Impact: Arbitrary Code Execution (ACE), Denial of Service (DoS), Information Disclosure. The attacker could gain control of the application or system.
    • Affected zlib Component: Potentially any part of zlib involved in decompression, including inflate(), memory allocation routines, and internal data structure handling. Specific vulnerabilities are tied to specific code flaws.
    • Risk Severity: Critical (if a remotely exploitable vulnerability exists; severity depends on the specific vulnerability)
    • Mitigation Strategies:
      • Update zlib: Crucially, use the latest stable version of zlib. This is the primary defense.
      • Memory Safety: Use memory-safe languages (Rust, Go) or memory safety features in C/C++ (AddressSanitizer, bounds checking).
      • Fuzz Testing: Perform fuzz testing of the application's zlib integration.
      • Input Validation: Validate compressed data integrity (if possible) before decompression (e.g., checksums).
      • Code Audits: Conduct regular code audits.

Threat: Integer Overflow

  • Description: An attacker provides specially crafted input that triggers an integer overflow within zlib's calculations, especially with very large compressed/uncompressed sizes. This can lead to incorrect memory allocation or other unexpected behavior.
    • Impact: Denial of Service (DoS), Potential Memory Corruption (depending on how the overflow is handled).
    • Affected zlib Component: Functions handling size calculations, like inflate(), compress(), and related memory allocation routines.
    • Risk Severity: High (can lead to DoS or potentially worse)
    • Mitigation Strategies:
      • Update zlib: Use the latest version of zlib.
      • Code Review: Carefully review code interacting with zlib, especially size calculations, to prevent overflows. Use appropriate data types and checks.
      • Input Validation: Limit input sizes to reasonable values.