Bug 863838 (CVE-2014-1947)

The SWAMPID for this issue is 56232.
This issue was rated as moderate.
Please submit fixed packages until 2014-02-27.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.

The SWAMPID for this issue is 56233.
This issue was rated as moderate.
Please submit fixed packages until 2014-02-27.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.

bugbot adjusting priority

wow

Do I understand correctly that

CVE-2014-1947 is addressed by
http://trac.imagemagick.org/changeset/13736
https://bugzilla.redhat.com/show_bug.cgi?id=1064098#c1

CVE-2014-1958 is addressed by
http://trac.imagemagick.org/changeset/14801
https://bugzilla.redhat.com/show_bug.cgi?id=1064098#c4
http://www.openwall.com/lists/oss-security/2014/02/13/5

CVE-2014-xxxx will be assigned to similar problem as in CVE-2014-1947 for older ImageMagick
https://bugzilla.redhat.com/show_bug.cgi?id=1064098#c1
http://www.openwall.com/lists/oss-security/2014/02/13/5

???

Please clarify and then assign back to me. Thanks!

2010-02-14  6.5.9-6 Cristy  <quetzlzacatenango@image...>
  * Support PSD RLE compression.

RLE compression is supported only by ImageMagick in 12.3 and 13.1.

To sum: if comment 4 is correct,
CVE-2014-1947, CVE-2014-xxxx: all distros affected with one of them, used same patch

     packet_size;
 
   unsigned char
-    layer_name[4];
+    layer_name[MaxTextExtent];
 
   unsigned long
     channel_size,


CVE-2014-1958: 12.3, 13.1 and sle12 affected

Stefan, could I do version update for sle12? It would be from 6.8.8-1 to 6.8.8-6 from Factory.

Otherwise both changesets
http://trac.imagemagick.org/changeset/13736
http://trac.imagemagick.org/changeset/14801

and whole mess outlined in comment 4 applies there.

Oh sorry. I forgot that from 6.8.8-5 there are also some changes to build system regarding to openjpeg2, so version update is not good now.

(In reply to comment #7)
> Otherwise both changesets
> http://trac.imagemagick.org/changeset/13736
> http://trac.imagemagick.org/changeset/14801

And that is actually not true. Only http://trac.imagemagick.org/changeset/14801 applies there.

To sum again:
CVE-2014-1947, CVE-2014-xxxx: 10sp3, 11, 12.3, 13.1
CVE-2014-1958: 12.3, 13.1 and sle12

*** Bug 864868 has been marked as a duplicate of this bug. ***

Okay, we have three CVEs now:

CVE-2014-1958
http://trac.imagemagick.org/changeset/14801

CVE-2014-1947
http://trac.imagemagick.org/changeset/13736

The clarified meaning of CVE-2014-1947 is now the vulnerability in
older ImageMagick versions (such as 6.5.4) that use the "L%02ld"
string. The root cause here is that the code did not cover the case of
more than 99 layers, which is apparently allowable but relatively
uncommon. This has a resultant buffer overflow, e.g, L99\0 is safe but
L100\0 is unsafe. When the overflow occurs, it can be described as "1
or more bytes too many."

CVE-2014-2030

A new ID of CVE-2014-2030 is now assigned for the vulnerability in
newer ImageMagick versions that use the "L%06ld" string. The root
cause here is that the code did not recognize the relationship between
the 8 (or more) characters in "L%06ld" and the actual buffer size.
This has a resultant buffer overflow of "4 or more bytes too many."

Thanks for clarification, I take it as 'yes'.

(In reply to comment #10)
> To sum again:
> CVE-2014-1947, CVE-2014-xxxx: 10sp3, 11, 12.3, 13.1
> CVE-2014-1958: 12.3, 13.1 and sle12

This now changes to:

CVE-2014-1947: 10sp3, 11, 
CVE-2014-2030: 12.3, 13.1
CVE-2014-1958: 12.3, 13.1 and sle12

Packages submitted.

Thanks!

Any idea if we also need to fix GraphicsMagick?

GraphicsMagick

(1) CVE-2014-1947 or CVE-2014-2030:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am reluctant to say strict 'yes' but is seems so: from sle11 to factory we have

$ grep layer_name coders/psd.c | grep -v '[1]'
    layer_name[4];
          (void) sprintf((char *) layer_name, "L%02d", layer_count++ );
          WritePascalString( image, (char*)layer_name, 4 );

so at least one byte overflow as far as I can see. CVE-2014-1947 applies here as far as I can see if layer_count is not bound somewhere (don't think so).

(2) CVE-2014-1958
~~~~~~~~~~~~~~~~~
GraphicsMagick doesn't seem to support PSD RLE compression. I don't think this CVE relates to it.

If this is all, "sprintf" will only abort the tool, as the static _FORTIFY_SOURCE overflow checker would trigger here (known sized target char array).



ImageMagick does it via:
        (void) FormatMagickString((char *) layer_name,MaxTextExtent,"L%02ld",

which will not trigger the compile time overflow checker. (The runtime checker might trigger or not, hard to say.)

so i would just not fix GraphicsMagick.

opensuse updates will be released soonish, so lets close

Update released for: ImageMagick, ImageMagick-debuginfo, ImageMagick-debugsource, ImageMagick-devel, ImageMagick-extra, libMagick++-devel, libMagick++1, libMagickCore1, libMagickCore1-32bit, libMagickCore1-64bit, libMagickCore1-x86, libMagickWand1, libMagickWand1-32bit, libMagickWand1-64bit, libMagickWand1-x86, perl-PerlMagick
Products:
SLE-DEBUGINFO 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP3 (i386, x86_64)
SLE-SDK 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP3 (i386, x86_64)

openSUSE-SU-2014:0362-1: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 863838
CVE References: CVE-2014-1958,CVE-2014-2030
Sources used:
openSUSE 13.1 (src):    ImageMagick-6.8.6.9-2.8.1
openSUSE 12.3 (src):    ImageMagick-6.7.8.8-4.9.1

openSUSE-SU-2014:0369-1: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 863838
CVE References: CVE-2014-1958,CVE-2014-2030
Sources used:
openSUSE 11.4 (src):    ImageMagick-6.6.5.8-8.74.1