|Summary:||CVE-2019-12402 apache-commons-compress: Infinite loop in name encoding algorithm|
|Product:||[Other] Security Response||Reporter:||Pedro Sampaio <psampaio>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||aboyko, aileenc, akoufoud, alazarot, almorale, anstephe, asoldano, atangrin, bbaranow, bibryam, bmaxwell, brian.stansberry, cdewolf, chazlett, darran.lofthouse, dblechte, decathorpe, dfediuck, dkreling, dosoudil, drieden, eedri, eleandro, eric.wittmann, etirelli, ganandan, ggaughan, gmalinko, gvarsami, hbraun, hhorak, ibek, iweiss, janstey, java-maint, java-sig-commits, jawilson, jcoleman, jjelen, jochrist, jolee, jorton, jperkins, jross, jschatte, jstastny, jwon, kconner, krathod, kverlaen, kwills, ldimaggi, lgao, mcascell, mgoldboi, michal.skrivanek, mizdebsk, mkoncek, mnovotny, msochure, msvehla, nwallace, pantinor, pjindal, pmackay, rguimara, rrajasek, rstancel, rsvoboda, rsynek, rwagner, sbonazzo, sdaley, sherold, smaestri, SpikeFedora, stewardship-sig, tcunning, tkirby, tom.jenkinson, vhalbert, yturgema|
|Fixed In Version:||apache-commons-compress 1.19||Doc Type:||If docs needed, set a value|
A resource consumption vulnerability was discovered in apache-commons-compress in the way NioZipEncoding encodes filenames. Applications that use Compress to create archives, with one of the filenames within the archive being controlled by the user, may be vulnerable to this flaw. A remote attacker could exploit this flaw to cause an infinite loop during the archive creation, thus leading to a denial of service.
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1783977, 1761797, 1764641|
Description Pedro Sampaio 2019-10-23 13:54:38 UTC
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
Comment 1 Pedro Sampaio 2019-10-23 13:54:52 UTC
Created apache-commons-compress tracking bugs for this issue: Affects: fedora-all [bug 1764641]
Comment 2 Mauro Matteo Cascella 2019-12-11 16:01:18 UTC
Comment 3 Mauro Matteo Cascella 2019-12-12 11:05:39 UTC
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.
Comment 9 Mauro Matteo Cascella 2019-12-12 19:05:06 UTC
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.
Comment 13 Mauro Matteo Cascella 2019-12-13 11:42:08 UTC
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
Comment 19 Eric Christensen 2019-12-16 16:28:56 UTC
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.
Comment 20 Jonathan Christison 2020-10-26 18:15:07 UTC
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)