Skip to content

Latest commit

 

History

History
67 lines (56 loc) · 6.27 KB

File metadata and controls

67 lines (56 loc) · 6.27 KB

Threat Model Analysis for madler/zlib

Description: An attacker crafts malicious compressed data that, when decompressed by zlib, causes zlib to write data beyond the allocated heap buffer. This is achieved by manipulating compressed data structures to cause incorrect size calculations or by exploiting vulnerabilities in decompression algorithms. The attacker aims to overwrite heap memory regions. * Impact: Arbitrary code execution, application crash, data corruption, denial of service. * Affected zlib component: Decompression functions (e.g., inflate, inflateBack), memory allocation within decompression. * Risk Severity: Critical * Mitigation Strategies: * Use the latest stable version of zlib with known buffer overflow vulnerabilities patched. * Validate and sanitize compressed data before decompression, if possible. * Implement resource limits on decompression size and time. * Employ memory safety tools during development and testing (e.g., AddressSanitizer, Valgrind). * Consider using operating system-level memory protection mechanisms (e.g., ASLR, DEP). * Run decompression in a sandboxed environment with limited privileges.

Description: Similar to heap buffer overflow, but the attacker crafts compressed data to overflow stack-allocated buffers during zlib decompression. This could be achieved by exploiting vulnerabilities in how zlib manages stack memory during decompression, potentially by providing deeply nested or recursive compressed structures. The attacker aims to overwrite stack memory, including return addresses. * Impact: Arbitrary code execution, application crash, denial of service. * Affected zlib component: Decompression functions (e.g., inflate, inflateBack), stack usage within decompression algorithms. * Risk Severity: Critical * Mitigation Strategies: * Use the latest stable version of zlib with known stack buffer overflow vulnerabilities patched. * Limit the recursion depth or complexity of compressed data processed by zlib. * Employ stack protection mechanisms provided by compilers and operating systems (e.g., stack canaries). * Use memory safety tools during development and testing (e.g., AddressSanitizer, Valgrind). * Run decompression in a sandboxed environment with limited privileges.

Description: An attacker provides compressed data that triggers integer overflows in zlib's size calculations during decompression. This can lead to allocating smaller-than-required buffers, which are then overflowed when zlib attempts to write decompressed data into them. The attacker manipulates size fields in the compressed data to cause these overflows. * Impact: Heap or stack buffer overflow, arbitrary code execution, application crash, data corruption, denial of service. * Affected zlib component: Size calculation logic within decompression functions (e.g., inflate, inflateBack), memory allocation based on calculated sizes. * Risk Severity: Critical * Mitigation Strategies: * Use the latest stable version of zlib with known integer overflow vulnerabilities patched. * Ensure zlib is compiled with compiler flags that provide integer overflow protection (if available and effective). * Implement checks on calculated sizes before memory allocation to ensure they are within reasonable bounds. * Use memory safety tools during development and testing (e.g., AddressSanitizer, Valgrind).

Description: An attacker crafts a highly compressed archive (zip bomb) that, when decompressed by zlib, expands to an extremely large size. Decompressing this archive consumes excessive CPU resources, causing the application to become unresponsive or crash due to CPU exhaustion. The attacker aims to overload the server or application processing the compressed data. * Impact: Denial of service, application unavailability, service disruption. * Affected zlib component: Decompression functions (e.g., inflate, inflateBack), CPU usage during decompression. * Risk Severity: High * Mitigation Strategies: * Implement limits on the maximum decompressed size allowed. * Implement timeouts for decompression operations. * Monitor CPU usage during decompression and terminate processes exceeding thresholds. * Scan compressed files for known zip bomb patterns (though detection can be complex). * Rate limit decompression requests, especially from untrusted sources.

Description: Similar to a compression bomb, but focused on memory consumption. An attacker crafts compressed data that decompresses to a very large size, causing zlib to allocate excessive memory. This can lead to application crashes due to out-of-memory errors or system instability due to memory pressure. The attacker aims to exhaust the memory resources of the system or application. * Impact: Denial of service, application unavailability, system instability, service disruption. * Affected zlib component: Decompression functions (e.g., inflate, inflateBack), memory allocation during decompression. * Risk Severity: High * Mitigation Strategies: * Implement strict limits on the maximum decompressed size allowed. * Monitor memory usage during decompression and terminate processes exceeding thresholds. * Set resource limits on processes performing decompression (e.g., using cgroups or similar mechanisms). * Validate declared uncompressed size in compressed data headers against predefined limits before decompression. * Rate limit decompression requests, especially from untrusted sources.