Memory Exhaustion Vulnerability in Numeric.readFloat
Summary
HSEC-2023-0007: readFloat: memory exhaustion with large exponent. Affects base versions >= 3.0.3.1. No fix is published. How to fix ↓
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
The Numeric.readFloat function is a part of the base package in the Haskell ecosystem. It is used to convert a string representation of a number into a floating-point value. The function is defined for all types that are instances of the RealFrac type class. The RealFrac type class does not impose any bounds on the size of representable values, making it susceptible to memory exhaustion with large exponents. This vulnerability affects the base package starting from version 3.0.3.1. The toml-reader package, specifically version 0.1.0.0, also includes this vulnerable function.
Vulnerability Detail
The readFloat function in Numeric module can cause memory exhaustion when processing a number expressed in scientific notation with a very large exponent. This can lead to a denial of service (DoS) attack, as the function's time and memory consumption are linear in the size of the number. The vulnerability has been observed to cause significant slowdowns, with processing times increasing exponentially with the exponent size. The issue was detected in the toml-reader package version 0.1.0.0 and has been mitigated in version 0.2.0.0 by immediately returning Infinity when the exponent is too large to process.
How To Fix
No fixed version is published for this vulnerability.
Tip — Not sure whether your app is affected? Vulert can check the versions your app actually runs. Scan free →
Workaround
If updating the code or package is not immediately feasible, a workaround for this vulnerability is to manually perform bounds checks on the exponent before calling the readFloat function. This can be done by parsing the exponent as an integer and comparing it to a predefined threshold. If the exponent exceeds the threshold, the function can return a default value or handle the case separately to avoid memory exhaustion.
Conclusion
The memory exhaustion vulnerability in Numeric.readFloat can lead to denial of service attacks by consuming excessive memory when processing large numbers with large exponents. It is important to update the code to use the read function or upgrade to a fixed version of the toml-reader package. For further support on vulnerability remediation, please contact DevNack.com.
See every vulnerability recorded for base →
FAQ
The vulnerability can be exploited to cause a denial of service (DoS) attack by consuming excessive memory and slowing down the processing of large numbers with large exponents.
The base package in the Haskell ecosystem is affected starting from version 3.0.3.1. The toml-reader package version 0.1.0.0 is also affected, but the vulnerability has been fixed in version 0.2.0.0.
To mitigate this vulnerability, it is recommended to use the read function instead of readFloat. The read function performs bounds checks on the exponent, preventing memory exhaustion. Alternatively, developers can upgrade to a version of the toml-reader package that includes the fix.
There are no known exploits for this vulnerability at the moment. However, the memory exhaustion caused by processing large numbers with large exponents can be leveraged for denial of service attacks.
Yes, the vulnerability has been fixed in version 0.2.0.0 of the toml-reader package. It is recommended to upgrade to this version or a later one to ensure the vulnerability is addressed.
Related vulnerabilities
Recent vulnerabilities recorded for base.
