The file name encoding algorithm used internally in Apache Commons Compress 1.15 to 1.18 can get into an infinite loop when faced with specially crafted inputs. This can lead to a denial of service attack if an attacker can choose the file names inside of an archive created by Compress. References: https://lists.apache.org/thread.html/308cc15f1f1dc53e97046fddbac240e6cd16de89a2746cf257be7f5b@%3Cdev.commons.apache.org%3E https://lists.apache.org/thread.html/54cc4e9fa6b24520135f6fa4724dfb3465bc14703c7dc7e52353a0ea@%3Ccommits.creadur.apache.org%3E https://bugzilla.redhat.com/show_bug.cgi?id=1761797
Created apache-commons-compress tracking bugs for this issue: Affects: fedora-all [bug 1764641]
Upstream fix: https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commitdiff;h=4ad5d80a6272e007f64a6ac66829ca189a8093b9
The flaw lies in the encode() method of NioZipEncoding class, which leverages java.nio to encode names. Specifically, the file name is encoded repeatedly, until there are no remaining characters in the input buffer. The encoder consumes characters from the input buffer, translates them, and writes the resulting bytes to an output buffer. During this process the exit condition UNDERFLOW (meaning that either the input buffer has been completely consumed or there is insufficient input) is not taken into account, leading to a possible infinite loop.
Class ZipArchiveOutputStream creates an output stream for writing files in the ZIP file format. The flaw is triggered when calling the putArchiveEntry() method with a carefully crafted ArchiveEntry, whose name is then encoded by the aforementioned encoding algorithm used internally in Apache Commons Compress.
The fallback zip encoding implementation that leverages java.io has been superseded in favor of NIO based encoding (java.nio) in Compress version 1.15. The UNDERFLOW exit condition in NioZipEncoding class has been removed from the while loop in the same version 1.15. https://github.com/apache/commons-compress/blob/rel/1.15/RELEASE-NOTES.txt#L55 https://issues.apache.org/jira/browse/COMPRESS-410 https://github.com/apache/commons-compress/commit/cec72ce690353c90f3867191d7e657ba59ed2612#diff-8a69e197c08fae1d66ccd13fc61ff8c5L201 https://github.com/apache/commons-compress/commit/a67bdc013c9fd965abaca375b9b47554a115f40e#diff-91e86934da9af58ac25a7a6f1c55e314L133
Statement: This issue does not affect the versions of apache-commons-compress as shipped with Red Hat Enterprise Linux 7, and the versions of rh-java-common-apache-commons-compress and rh-maven35-apache-commons-compress as shipped with Red Hat Software Collections 3, as they used a fallback zip encoding implementation (leveraging java.io) to encode filenames. This issue does not affect the versions of rh-maven36-apache-commons-compress as shipped with Red Hat Software Collection 3 as they already include the patch.
Marking Red Hat Fuse 7 as having a moderate impact, the use of Apache Commons Compress as part of Fuse Online is in the Project Generation phase and is not something made available as part of a service to the network (AV:N -> AV:L), the naming of the files is also controlled by the local user/developer, an attacker would need to invest a measurable amount of effort to alter the target environment to exploit the vulnerability (AC:L -> AC:H)
This issue has been addressed in the following products: Red Hat Fuse 7.9 Via RHSA-2021:3140 https://access.redhat.com/errata/RHSA-2021:3140
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-12402