Skip to content

Latest commit

 

History

History
40 lines (33 loc) · 4.45 KB

File metadata and controls

40 lines (33 loc) · 4.45 KB

Threat Model Analysis for boostorg/boost

Description: An attacker sends specially crafted network packets to an application using Boost.Asio. If the application's code using Boost.Asio doesn't properly validate the size of incoming data before copying it into a fixed-size buffer, an attacker can cause a buffer overflow. This allows the attacker to overwrite adjacent memory regions, potentially leading to arbitrary code execution. Impact: Remote Code Execution, Denial of Service, Information Disclosure. Boost Component Affected: Boost.Asio (Networking Library, specifically buffer handling in asynchronous operations). Risk Severity: Critical Mitigation Strategies: * Use Boost.Asio's dynamic buffer classes: Employ boost::asio::dynamic_buffer or similar mechanisms that automatically resize buffers as needed, preventing overflows. * Strict input validation: Validate the size and format of all network data received through Boost.Asio before processing it. * Bounds checking: Implement explicit bounds checking when copying data into fixed-size buffers, even when using Boost.Asio. * Regularly update Boost: Ensure you are using the latest stable version of Boost.Asio to benefit from bug fixes and security patches.

Description: An attacker provides a specially crafted regular expression and input string to an application using Boost.Regex. Certain complex regular expressions can exhibit catastrophic backtracking when matched against specific inputs, leading to extremely long processing times and excessive CPU consumption. This can cause a denial of service. Impact: Denial of Service (CPU exhaustion, application slowdown or crash). Boost Component Affected: Boost.Regex (Regular Expression Library). Risk Severity: High Mitigation Strategies: * Carefully design regular expressions: Avoid overly complex or nested regular expressions that are prone to backtracking. Test regexes against various inputs, including potentially malicious ones. * Input validation and sanitization: Validate and sanitize input strings before applying regular expressions. Limit the length of input strings. * Set timeouts for regex matching: Implement timeouts when using Boost.Regex to prevent regex matching from running indefinitely. * Use alternative regex engines (if appropriate): In some cases, alternative regex engines might be less susceptible to ReDoS attacks. However, ensure compatibility and feature parity. * Consider using simpler parsing techniques: If regular expressions are used for parsing relatively simple structures, consider using simpler parsing techniques or dedicated parsing libraries (like Boost.Spirit) which might offer better performance and security in specific scenarios.

Description: An attacker uploads or provides a specially crafted compressed archive (e.g., ZIP file) to an application using Boost.Iostreams for decompression. This archive, known as an "archive bomb" or "zip bomb," is designed to decompress into an extremely large amount of data, potentially exceeding available disk space or memory, leading to resource exhaustion and denial of service. Impact: Denial of Service (Disk space exhaustion, memory exhaustion, application crash). Boost Component Affected: Boost.Iostreams (I/O Streams Library, specifically compression/decompression filters). Risk Severity: High Mitigation Strategies: * Limit decompression size: Implement limits on the maximum size of decompressed data allowed by Boost.Iostreams. Abort decompression if the limit is exceeded. * Resource quotas: Enforce resource quotas (e.g., disk space, memory) for processes handling archive decompression. * Input validation: Validate the source and type of archive files being processed. Restrict allowed archive types and sources if possible. * Progress monitoring and timeouts: Monitor decompression progress and set timeouts to prevent decompression from running indefinitely. * Consider alternative decompression methods (if appropriate): In some cases, using system-level decompression utilities with resource limits might be more secure than relying solely on library-level decompression.