Memory Exhaustion in Furl Perl Library

Executive Summary

Furl versions through 3.15 for Perl are vulnerable to memory exhaustion due to unbounded decompression of HTTP responses. The library inflates response bodies with gzip, x-gzip, or deflate Content-Encoding and appends the output to a response string without any size limit, even if the request did not ask for compression. This allows a small compressed response to expand significantly, consuming excessive memory and potentially crashing the client process.

Useful 0 Not Useful 0

Detection Guidance

Monitor memory usage during HTTP requests with tools like 'top' or 'htop' while using Furl. Check for processes consuming excessive memory unexpectedly. Inspect network traffic for responses with gzip, x-gzip, or deflate Content-Encoding headers that may indicate compression without explicit client request.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by causing your application to run out of memory and crash if it processes a malicious server's compressed response. Attackers could exploit this to disrupt services or perform denial-of-service attacks on systems using vulnerable Furl versions.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability could indirectly impact compliance with GDPR or HIPAA by enabling denial-of-service attacks that disrupt system availability, which is a requirement under both regulations. Memory exhaustion may cause service disruptions, potentially violating availability principles in GDPR Article 32 and HIPAA Security Rule requirements for access and integrity.

Useful 0 Not Useful 0

Mitigation Strategies

Update Furl to the latest patched version that includes decompression size limits. Avoid using Furl for requests where compression is not explicitly requested. Implement client-side memory limits for HTTP responses to prevent exhaustion.

Useful 0 Not Useful 0