I see that David made a build for Mageia 6:
apache-commons-compress-1.12-1.1.mga6
apache-commons-compress-javadoc-1.12-1.1.mga6

from apache-commons-compress-1.12-1.1.mga6.src.rpm

but the Cauldron build failed:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20180320060325.daviddavid.duvel.10887/log/apache-commons-compress-1.16.1-1.mga7/build.0.20180320060404.log

Fedora has issued advisories for this on March 27:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/UJ7GKBUCVEHQVGOXIOT6EWCRVDZJMHGK/
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HU23EOCA5XLFZRO22HP4PWIVDJHQMMWO/

Another security issue, fixed upstream in 1.18:
http://openwall.com/lists/oss-security/2018/08/16/2

Mageia 5 and Mageia 6 are also affected.

Status comment: Fixed upstream in 1.16 => Fixed upstream in 1.18
Summary: apache-commons-compress new security issue CVE-2018-1324 => apache-commons-compress new security issues CVE-2018-1324 and CVE-2018-11771

Fedora has issued an advisory for the new issue on October 9:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FLKWBUZ7KVAJV6VZAY2UYW5JIEVMRT2R/

apache-commons-compress-1.17-2.mga7 uploaded for Cauldron to fix this.

Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Advisory:
========================

Updated apache-commons-compress packages fix security vulnerabilities:

A flaw was found in Apache Commons Compress versions 1.11 to 1.15. A specially
crafted ZIP archive can be used to cause an infinite loop inside of Apache
Commons Compress' extra field parser used by the ZipFile and
ZipArchiveInputStream classes in versions 1.11 to 1.15. This can be used to
mount a denial of service attack against services that use Compress' zip
package (CVE-2018-1324).

Apache Commons Compress versions 1.7 to 1.17 are vulnerable to a denial of
service attack via crafted ZIP archive. When reading a specially crafted ZIP
archive, the read method of ZipArchiveInputStream can fail to return the
correct EOF indication after the end of the stream has been reached.  When
combined with a java.io.InputStreamReader this can lead to an infinite stream,
which can be used to mount a denial of service attack against services that
use Compress' zip package (CVE-2018-11771).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1324
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11771
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/UJ7GKBUCVEHQVGOXIOT6EWCRVDZJMHGK/
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FLKWBUZ7KVAJV6VZAY2UYW5JIEVMRT2R/
========================

Updated packages in core/updates_testing:
========================
apache-commons-compress-1.12-1.2.mga6
apache-commons-compress-javadoc-1.12-1.2.mga6

from apache-commons-compress-1.12-1.2.mga6.src.rpm

Severity: normal => major
Assignee: java => qa-bugs

Hi all,
I am not finding apache-commons-compress-1.12-1.2



I'm only finding 1.12-1.1 in the test repos.

Please confirm 1.12-1.2

CC: (none) => brtians1

It is 1.2.

Found it.

Pulled in both files and wrote a tiny java program that uses the jar files for a single file zip and unzip.

I will attach the code.

Only doing x86_64 since these files are architecture agnostic.

Created attachment 10632 [details]
java code for creating a zip entry

You'll need the openjdk compiler installed

To compile the compress routine.

javac -cp .:"/usr/share/java/commons-compress.jar" Zipup.java


To run the compress routine

java -cp .:"/usr/share/java/commons-compress.jar" Zipup <uncompressed input file> <compressed_name.zip>

Worked for me.

Created attachment 10633 [details]
java code for extracting a zip entry

Compile using:

javac -cp .:"/usr/share/java/commons-compress.jar" Zipextract.java


Execute using

java -cp .:"/usr/share/java/commons-compress.jar" Zipextract <zipped file> <directory to extract to>

Note this only pulls the first entry, I didn't feel like writing a loop in the code.

Looking for PoCs, found this:

CVE-2018-1324
https://issues.apache.org/jira/browse/COMPRESS-432
difflist_fsbwserver.f-secure.com_80_583109529_2.zip

All at sea as far as java is concerned but Brian's attachments were invaluable.
Had to define the CLASSPATH variable.
$ echo $CLASSPATH
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191-1.b12.1.mga6.x86_64/jre
and extend it on the fly as Brian indicates in comment 11.

Before update:

$ mkdir poc
$ javac -cp .:"/usr/share/java/apache-commons-compress.jar" Zipextract.java
$ ls
difflist_fsbwserver.f-secure.com_80_583109529_2.zip  Zipextract.class
report.22787                                         Zipextract.java
report.22787~                                        Zipup.class
tip                                                  Zipup.java
$ java -cp .:"/usr/share/java/apache-commons-compress.jar" Zipextract difflist_fsbwserver.f-secure.com_80_583109529_2.zip poc
[lcl@difda apache-commons-compress]$ ll poc
-rw-r--r-- 1 lcl lcl 887 Jan  3 09:55 aqu.index
$ file poc/aqu.index
poc/aqu.index: data
Note that the original corrupted zip file is much bigger.
$ ll *.zip
-rw-rw-r-- 1 lcl lcl 416772 Jan  3 01:13 difflist_fsbwserver.f-secure.com_80_583109529_2.zip

No looping, which suggests that the bug had already been fixed.

Updated and recompiled Zipextract.java.

After update:

$ rm -f poc/*
$ java -cp .:"/usr/share/java/apache-commons-compress.jar" Zipextract difflist_fsbwserver.f-secure.com_80_583109529_2.zip poc
$ ll poc
-rw-r--r-- 1 lcl lcl 887 Jan  3 10:24 aqu.index

Identical result, which would confirm that the endless loop issue had already been fixed.

Thanks Brian.

CC: (none) => tarazed25

Thank you both for the tests. Advisory from comment 6, validating.

Keywords: (none) => advisory, validated_update
CC: (none) => lewyssmith, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0001.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED