Also reported in bug 582364 comment 1 Per ${URL}: TALOS-CAN-0094, Out-of-Bounds Read Vulnerability, [CVE-2016-2335] An out-of-bounds read vulnerability exists in the way 7-Zip handles Universal Disk Format (UDF) files. The UDF file system was meant to replace the ISO-9660 file format, and was eventually adopted as the official file system for DVD-Video and DVD-Audio. Central to 7-Zip’s processing of UDF files is the CInArchive::ReadFileItem method. Because volumes can have more than one partition map, their objects are kept in an object vector. To start looking for an item, this method tries to reference the proper object using the partition map’s object vector and the "PartitionRef" field from the Long Allocation Descriptor. Lack of checking whether the "PartitionRef" field is bigger than the available amount of partition map objects causes a read out-of-bounds and can lead, in some circumstances, to arbitrary code execution. TALOS-CAN-0093, Heap Overflow Vulnerability, [CVE-2016-2334] An exploitable heap overflow vulnerability exists in the Archive::NHfs::CHandler::ExtractZlibFile method functionality of 7-Zip. In the HFS+ file system, files can be stored in compressed form using zlib. There are three different ways of keeping data in that form depending on the size of the data. Data from files whose compressed size is bigger than 3800 bytes is stored in a resource fork, split into blocks. Block size information and their offsets are kept in a table just after the resource fork header. Prior to decompression, the ExtractZlibFile method reads the block size and its offset from the file. After that, it reads block data into static size buffer "buf". There is no check whether the size of the block is bigger than size of the buffer "buf", which can result in a malformed block size which exceeds the mentioned "buf" size. This will cause a buffer overflow and subsequent heap corruption. Conclusion Sadly, many security vulnerabilities arise from applications which fail to properly validate their input data. Both of these 7-Zip vulnerabilities resulted from flawed input validation. Because data can come from a potentially untrusted source, data input validation is of critical importance to all applications’ security. Talos has worked with 7-Zip to responsibly disclose, and then patch these vulnerabilities. Users are urged to update their vulnerable versions of 7-Zip to the latest revision, version 16.00, as soon as possible.
waiting on release so I can update, should be auto-notified when it is released.
7-Zip 16.00 was released on May 10 [1] and is available for download [2]. [1] http://www.7-zip.org/history.txt [2] http://www.7-zip.org/download.html
that's not p7zip though :(
https://sourceforge.net/p/p7zip/discussion/383043/thread/9d0fb86b/
so, not an issue?
As far as I understand, it is not an issue for the 7za binary. The discussion does not say anything about the other binaries.
p7zip 16.02 was released upstream, hopefully fixing these issues.
Ok, I've updated the package, 16.02 is now out. Should we cc arches?
CVE-2016-2335 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2335): The CInArchive::ReadFileItem method in Archive/Udf/UdfIn.cpp in 7zip 9.20 and 15.05 beta and p7zip allows remote attackers to cause a denial of service (out-of-bounds read) or execute arbitrary code via the PartitionRef field in the Long Allocation Descriptor in a UDF file.
Still trying to track that the vulnerabilities have been patched.
Fixed version is in repository since https://gitweb.gentoo.org/repo/gentoo.git/commit/app-arch/p7zip?id=98be5eb1827845a1551e998392c603e692815ccc
@arches, please stabilize: =app-arch/p7zip-16.02-r1
amd64 stable
x86 stable
sparc stable
ia64 stable
ppc stable
hppa and ppc64 remain, do we care about these arches, I forget if the last council meeting made a hard decision here.
oops, got this confused with the memcached cleanup :D
ppc64 stable
Stable for HPPA.
New GLSA request filed. @ Maintainer(s): Please cleanup <app-arch/p7zip-16.02-r1!
cleaned up, removing self from cc
This issue was resolved and addressed in GLSA 201701-27 at https://security.gentoo.org/glsa/201701-27 by GLSA coordinator Aaron Bauman (b-man).
