Unbounded SAML message decompression in esaml allows memory exhaustion

Overview

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Affected

• handnot2/esaml >= deeb84378d5c82153b470e99d24f77c38afca14a < *
• arekinath/esaml >= deeb84378d5c82153b470e99d24f77c38afca14a < *
• esaml >= 0.1.0 < *
• dropbox/esaml >= deeb84378d5c82153b470e99d24f77c38afca14a < *

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.