[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#866516: stretch-pu: package unrar-nonfree/1:5.3.2-1+deb9u1



Control: tag -1 confirmed

Hi Felix,

Felix Geyer <fgeyer@debian.org> (2017-06-29):
> I'd like to fix CVE-2012-6706 in stretch, see #865461 for details.
> debdiff is attached.

This looks good to me, feel free to upload; thanks.

(Unimportant comment below.)

> diff -Nru unrar-nonfree-5.3.2/debian/changelog unrar-nonfree-5.3.2/debian/changelog
> --- unrar-nonfree-5.3.2/debian/changelog	2015-08-10 14:58:20.000000000 +0200
> +++ unrar-nonfree-5.3.2/debian/changelog	2017-06-28 00:10:20.000000000 +0200
> @@ -1,3 +1,12 @@
> +unrar-nonfree (1:5.3.2-1+deb9u1) stretch; urgency=medium
> +
> +  * Add bound checks for VMSF_DELTA, VMSF_RGB and VMSF_AUDIO paramters.
> +    - Backported from 5.5.5
> +    - CVE-2012-6706
> +    - Closes #865461
> +
> + -- Felix Geyer <fgeyer@debian.org>  Wed, 28 Jun 2017 00:10:20 +0200
> +
>  unrar-nonfree (1:5.3.2-1) unstable; urgency=medium
>  
>    * New upstream release (Closes: #759586)
> diff -Nru unrar-nonfree-5.3.2/debian/patches/CVE-2012-6706 unrar-nonfree-5.3.2/debian/patches/CVE-2012-6706
> --- unrar-nonfree-5.3.2/debian/patches/CVE-2012-6706	1970-01-01 01:00:00.000000000 +0100
> +++ unrar-nonfree-5.3.2/debian/patches/CVE-2012-6706	2017-06-22 20:25:06.000000000 +0200
> @@ -0,0 +1,44 @@
> +--- unrar-nonfree-5.3.2.org/rarvm.cpp
> ++++ unrar-nonfree-5.3.2/rarvm.cpp
> +@@ -965,7 +965,7 @@
> +       {
> +         int DataSize=R[4],Channels=R[0],SrcPos=0,Border=DataSize*2;
> +         SET_VALUE(false,&Mem[VM_GLOBALMEMADDR+0x20],DataSize);
> +-        if ((uint)DataSize>=VM_GLOBALMEMADDR/2)
> ++        if ((uint)DataSize>=VM_GLOBALMEMADDR/2 || (uint)Channels>MAX3_UNPACK_CHANNELS || Channels==0)
> +           break;
> + 
> +         // Bytes from same channels are grouped to continual data blocks,
> +@@ -984,7 +984,7 @@
> +         byte *SrcData=Mem,*DestData=SrcData+DataSize;
> +         const int Channels=3;
> +         SET_VALUE(false,&Mem[VM_GLOBALMEMADDR+0x20],DataSize);
> +-        if ((uint)DataSize>=VM_GLOBALMEMADDR/2 || Width<0 || PosR<0)
> ++        if ((uint)DataSize>=VM_GLOBALMEMADDR/2 || Width<0 || PosR<0 || DataSize<3 || Width>DataSize || PosR>2)
> +           break;
> +         for (int CurChannel=0;CurChannel<Channels;CurChannel++)
> +         {
> +@@ -1029,7 +1029,7 @@
> +         int DataSize=R[4],Channels=R[0];
> +         byte *SrcData=Mem,*DestData=SrcData+DataSize;
> +         SET_VALUE(false,&Mem[VM_GLOBALMEMADDR+0x20],DataSize);
> +-        if ((uint)DataSize>=VM_GLOBALMEMADDR/2)
> ++        if ((uint)DataSize>=VM_GLOBALMEMADDR/2 || (uint)Channels>128 || Channels==0)
> +           break;
> +         for (int CurChannel=0;CurChannel<Channels;CurChannel++)
> +         {
> +--- unrar-nonfree-5.3.2.orig/unpack.hpp
> ++++ unrar-nonfree-5.3.2/unpack.hpp
> +@@ -13,6 +13,12 @@
> + // from two data blocks.
> + #define MAX3_UNPACK_FILTERS      8192
> + 
> ++// Limit maximum number of channels in RAR3 delta filter to some reasonable
> ++// value to prevent too slow processing of corrupt archives with invalid
> ++// channels number. Must be equal or larger than v3_MAX_FILTER_CHANNELS.
> ++// No need to provide it for RAR5, which uses only 5 bits to store channels.
> ++#define MAX3_UNPACK_CHANNELS      1024
> ++
> + // Write data in 4 MB or smaller blocks. Must not exceed PACK_MAX_WRITE,
> + // so we keep number of buffered filter in unpacker reasonable.
> + #define UNPACK_MAX_WRITE     0x400000

(Funny to see a new definition for MAX3_UNPACK_CHANNELS but not for the
hardcoded 128. But I suppose this might be an artefact of backporting
the fix from a new upstream. Not a huge deal anyway.)

> diff -Nru unrar-nonfree-5.3.2/debian/patches/series unrar-nonfree-5.3.2/debian/patches/series
> --- unrar-nonfree-5.3.2/debian/patches/series	2013-08-15 16:56:10.000000000 +0200
> +++ unrar-nonfree-5.3.2/debian/patches/series	2017-06-22 20:20:22.000000000 +0200
> @@ -1 +1,2 @@
>  fix-buildflags
> +CVE-2012-6706


KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: