Bug#854727: Removal from stretch?
clone 854727 -1 retitle -1 zziplib: CVE-2017-5977 severity -1 important thanks hi On Sun, Jun 04, 2017 at 11:09:40AM +0200, Moritz Muehlenhoff wrote: > Moritz Muehlenhoff wrote: > > On Fri, Mar 24, 2017 at 07:41:03AM -0400, Scott Howard wrote: > > > I was contacted by someone at SUSE that is working on fixing the security > > > bugs - but even if successful, I don't know how good the quality will be > > > or > > > how much testing will be able to get done before stretch is released. > > > Removal might be safest option > > > > Unfortunately removal didn't work our for stretch and will have to wait > > for buster. > > Since the stretch release is coming close and since Scott is on the LowNMU > list I've uploaded an NMU. CVE-2017-5980 isn't mentioned in the patch > names, but I've confirmed with the reproducers that it's fixed as well. > > CVE-2017-5977 still needs to be checked, it might be fixed along with > zziplib-CVE-2017-5974.patch or zziplib-CVE-2017-5976.patch, but needs > further investigation. It's only a memory overread, so if it misses > the stretch release that's not a big deal. Cloning the bug to track possibile further update for CVE-2017-5977 in the BTS, since 854727 closed with the upload. Regards, Salvatore
Processed: Re: Bug#854727: Removal from stretch?
Processing commands for cont...@bugs.debian.org:
> clone 854727 -1
Bug #854727 {Done: Moritz Muehlenhoff } [src:zziplib] zziplib:
Multiple vulnerabilities
Bug 854727 cloned as bug 864150
> retitle -1 zziplib: CVE-2017-5977
Bug #864150 {Done: Moritz Muehlenhoff } [src:zziplib] zziplib:
Multiple vulnerabilities
Changed Bug title to 'zziplib: CVE-2017-5977' from 'zziplib: Multiple
vulnerabilities'.
> severity -1 important
Bug #864150 {Done: Moritz Muehlenhoff } [src:zziplib] zziplib:
CVE-2017-5977
Severity set to 'important' from 'grave'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
854727: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854727
864150: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864150
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#854727: Removal from stretch?
Moritz Muehlenhoff wrote: > On Fri, Mar 24, 2017 at 07:41:03AM -0400, Scott Howard wrote: > > I was contacted by someone at SUSE that is working on fixing the security > > bugs - but even if successful, I don't know how good the quality will be or > > how much testing will be able to get done before stretch is released. > > Removal might be safest option > > Unfortunately removal didn't work our for stretch and will have to wait > for buster. Since the stretch release is coming close and since Scott is on the LowNMU list I've uploaded an NMU. CVE-2017-5980 isn't mentioned in the patch names, but I've confirmed with the reproducers that it's fixed as well. CVE-2017-5977 still needs to be checked, it might be fixed along with zziplib-CVE-2017-5974.patch or zziplib-CVE-2017-5976.patch, but needs further investigation. It's only a memory overread, so if it misses the stretch release that's not a big deal. Cheers, Moritz
Bug#854727: Removal from stretch?
On 31.05.2017 22:55, Moritz Muehlenhoff wrote: > On Fri, Mar 24, 2017 at 07:41:03AM -0400, Scott Howard wrote: >> I was contacted by someone at SUSE that is working on fixing the security >> bugs - but even if successful, I don't know how good the quality will be or >> how much testing will be able to get done before stretch is released. >> Removal might be safest option That was probably me ;-) The patches I prepared were just that: patches to fix the issues at hand, e.g. check if a file offset is within range before fetching something from that offset. They fix the issues of the CVEs and will allow the zziplib to handle the corrupt archives attached to the CVEs. Most likely there are other places where the code will happily use part of an ASCII string as a file offset! In the end, the code might need to be more strict, rejecting a file if it looks corrupt. All in all, IMHO the code needs a thorough rework to properly check values and offsets and, as said, reject corrupt archives. Although zziplib is still quite high on my list of tasks, unfortunately at the moment I do not have enough time to do this, so either someone else will do it or I need to find some time for that, maybe next years hackweek. > Unfortunately removal didn't work our for stretch and will have to wait > for buster. > > I'm attaching the patches used by SuSE to address these vulnerabilities > (extracted from their srpm). > > Cheers, > Moritz > Josef
Bug#854727: Removal from stretch?
On Fri, Mar 24, 2017 at 07:41:03AM -0400, Scott Howard wrote:
> I was contacted by someone at SUSE that is working on fixing the security
> bugs - but even if successful, I don't know how good the quality will be or
> how much testing will be able to get done before stretch is released.
> Removal might be safest option
Unfortunately removal didn't work our for stretch and will have to wait
for buster.
I'm attaching the patches used by SuSE to address these vulnerabilities
(extracted from their srpm).
Cheers,
Moritz
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -216,12 +216,12 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
/* override sizes/offsets with zip64 values for largefile support */
zzip_extra_zip64 *block = (zzip_extra_zip64 *)
zzip_mem_entry_extra_block(item, ZZIP_EXTRA_zip64);
-if (block)
+if (block && ZZIP_GET16(block->z_datasize) >= (8 + 8 + 8 + 4))
{
-item->zz_usize = __zzip_get64(block->z_usize);
-item->zz_csize = __zzip_get64(block->z_csize);
-item->zz_offset = __zzip_get64(block->z_offset);
-item->zz_diskstart = __zzip_get32(block->z_diskstart);
+item->zz_usize = ZZIP_GET64(block->z_usize);
+item->zz_csize = ZZIP_GET64(block->z_csize);
+item->zz_offset = ZZIP_GET64(block->z_offset);
+item->zz_diskstart = ZZIP_GET32(block->z_diskstart);
}
}
/* NOTE:
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -173,6 +173,8 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
return 0; /* errno=ENOMEM; */
___ struct zzip_file_header *header =
zzip_disk_entry_to_file_header(disk, entry);
+if (!header)
+ { free(item); return 0; }
/* there is a number of duplicated information in the file header
* or the disk entry block. Theoretically some part may be missing
* that exists in the other, ... but we will prefer the disk entry.
Index: zziplib-0.13.62/zzip/mmapped.c
===
--- zziplib-0.13.62.orig/zzip/mmapped.c
+++ zziplib-0.13.62/zzip/mmapped.c
@@ -289,6 +289,8 @@ zzip_disk_entry_to_file_header(ZZIP_DISK
(disk->buffer + zzip_disk_entry_fileoffset(entry));
if (disk->buffer > file_header || file_header >= disk->endbuf)
return 0;
+if (ZZIP_GET32(file_header) != ZZIP_FILE_HEADER_MAGIC)
+return 0;
return (struct zzip_file_header *) file_header;
}
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -201,6 +201,7 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
{
void *mem = malloc(ext1 + 2);
item->zz_ext[1] = mem;
+ item->zz_extlen[1] = ext1 + 2;
memcpy(mem, ptr1, ext1);
((char *) (mem))[ext1 + 0] = 0;
((char *) (mem))[ext1 + 1] = 0;
@@ -209,6 +210,7 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
{
void *mem = malloc(ext2 + 2);
item->zz_ext[2] = mem;
+ item->zz_extlen[2] = ext2 + 2;
memcpy(mem, ptr2, ext2);
((char *) (mem))[ext2 + 0] = 0;
((char *) (mem))[ext2 + 1] = 0;
@@ -245,8 +247,10 @@ zzip_mem_entry_extra_block(ZZIP_MEM_ENTR
while (1)
{
ZZIP_EXTRA_BLOCK *ext = entry->zz_ext[i];
-if (ext)
+if (ext && (entry->zz_extlen[i] >= zzip_extra_block_headerlength))
{
+ char *endblock = (char *)ext + entry->zz_extlen[i];
+
while (*(short *) (ext->z_datatype))
{
if (datatype == zzip_extra_block_get_datatype(ext))
@@ -257,6 +261,10 @@ zzip_mem_entry_extra_block(ZZIP_MEM_ENTR
e += zzip_extra_block_headerlength;
e += zzip_extra_block_get_datasize(ext);
ext = (void *) e;
+ if (e >= endblock)
+ {
+ break;
+ }
;
}
}
Index: zziplib-0.13.62/zzip/memdisk.h
===
--- zziplib-0.13.62.orig/zzip/memdisk.h
+++ zziplib-0.13.62/zzip/memdisk.h
@@ -66,6 +66,7 @@ struct _zzip_mem_entry {
int zz_filetype; /* (from "z_filetype") */
char*zz_comment; /* zero-terminated (from "comment") */
ZZIP_EXTRA_BLOCK* zz_ext[3]; /* terminated by null in z_datatype */
+int zz_extlen[3]; /* length of zz_ext[i] in bytes */
}; /* the extra blocks are NOT converted */
#define _zzip_mem_disk_findfirst(_d_) ((_d_)->list)
Index: zziplib-0.13.62/z
Bug#854727: Removal from stretch?
I was contacted by someone at SUSE that is working on fixing the security bugs - but even if successful, I don't know how good the quality will be or how much testing will be able to get done before stretch is released. Removal might be safest option
Bug#854727: Removal from stretch?
Removing zziplib from stretch seems like a bit of an effort: $ apt-cache rdepends libzzip-0-13 libzzip-0-13 Reverse Depends: libzzip-dev zziplib-bin libacexml-6.3.3 texlive-binaries swftools libogre-1.9.0v5 mpd milkytracker lua-zip libgetdata7 Cheers, -Hilko
