Denial of Service in Eclipse Parsson JSON Parser

Executive Summary

This vulnerability exists in Eclipse Parsson JSON parser versions before 1.1.8, where there was no enforced maximum limit on the number of characters consumed while parsing a single JSON document.

An attacker can exploit this by sending very large JSON documents containing large arrays, objects, strings, numbers, whitespace, or deeply nested structures. Because the parser does not limit the size, it can consume excessive CPU and memory resources.

This excessive resource consumption can lead to a denial of service (DoS) condition, where the application becomes unresponsive or crashes due to running out of memory or CPU.

The vulnerability was fixed in version 1.1.8 by introducing a configurable maximum parsing limit, which defaults to 15 million characters consumed during parsing.

Useful 0 Not Useful 0

Impact Analysis

If your application uses Eclipse Parsson versions before 1.1.8 to parse JSON input, especially from untrusted or attacker-controlled sources, it can be vulnerable to denial of service attacks.

An attacker can send a very large JSON payload that causes the parser to consume excessive memory and CPU, potentially exhausting system resources.

For example, a 100MB JSON input could exhaust a 512MB heap memory, causing the application to crash or become unresponsive.

This can disrupt service availability, degrade performance, and potentially cause downtime for applications exposing public endpoints that accept JSON.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring for applications that parse JSON input using Eclipse Parsson versions before 1.1.8, especially if those applications accept large or attacker-controlled JSON documents.

Detection can involve checking the version of the Parsson library in use to see if it is older than 1.1.8, which lacks the maximum parsing limit.

On systems where you have access to the application or its dependencies, you can use commands to identify the Parsson version, for example:

• For Java applications, inspect the dependency tree using Maven: `mvn dependency:tree | grep parsson`
• Check the JAR files in your application's classpath for parsson version: `jar tf parsson-*.jar | grep VERSION` or check the filename for version info.

Additionally, network detection could involve monitoring for unusually large JSON payloads sent to endpoints that accept JSON, which might indicate attempts to exploit this vulnerability.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade the Eclipse Parsson library to version 1.1.8 or later, which introduces a configurable maximum parsing limit to prevent excessive resource consumption.

If upgrading immediately is not possible, consider implementing application-level limits on the size of JSON inputs accepted, such as limiting the size of HTTP request bodies or validating input sizes before parsing.

Review and apply the patch introduced in Pull Request #169, which adds a maxParsingLimit configuration with a default limit of 15 million characters to prevent denial-of-service attacks.

Monitor application logs for exceptions related to JSON parsing limits or out-of-memory errors that could indicate exploitation attempts.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability in Eclipse Parsson allows an attacker to cause a denial of service by forcing the JSON parser to consume excessive CPU and memory through very large JSON documents. This can lead to application unavailability.

While the CVE description and resources do not explicitly mention compliance with standards such as GDPR or HIPAA, denial of service vulnerabilities can indirectly affect compliance by impacting the availability of systems that process sensitive data.

Standards like GDPR and HIPAA require organizations to ensure the availability and resilience of systems handling personal or protected health information. A denial of service vulnerability that can be exploited to disrupt service may therefore pose a risk to meeting these availability requirements.

However, there is no direct information in the provided context linking this vulnerability to specific compliance failures or breaches of these regulations.

Useful 0 Not Useful 0