You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2023/06/16 15:32:00 UTC

[jira] [Commented] (CAMEL-19463) CVE 2023-34455 - Vulnerability identified with Camel-Kafka

    [ https://issues.apache.org/jira/browse/CAMEL-19463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733559#comment-17733559 ] 

Claus Ibsen commented on CAMEL-19463:
-------------------------------------

You need to report this to Apache Kafka as they should upgrade

[INFO] +- org.apache.kafka:kafka-clients:jar:3.4.1:compile
[INFO] |  +- com.github.luben:zstd-jni:jar:1.5.2-1:runtime
[INFO] |  +- org.lz4:lz4-java:jar:1.8.0:runtime
[INFO] |  \- org.xerial.snappy:snappy-java:jar:1.1.8.4:runtime

> CVE 2023-34455 - Vulnerability identified with Camel-Kafka
> ----------------------------------------------------------
>
>                 Key: CAMEL-19463
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19463
>             Project: Camel
>          Issue Type: Dependency upgrade
>          Components: camel-kafka
>            Reporter: Sasikumar Muthukrishnan Sampath
>            Assignee: Andrea Cosentino
>            Priority: Minor
>
> A new vulnerability CVE-2023-34455 is identified with camel-kafka dependencies. The vulnerability is coming from snappy-java:1.1.8.4
> Version 1.1.10.1 contains a patch for this issue. Please upgrade the snappy-java version to fix this issue
>  
> snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1.
> The code in the function hasNextChunk in the fileSnappyInputStream.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.
> 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.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)