Re: information on "ImageMagick PSD Images Processing RLE Decoding Buffer Overflow Vulnerability"

[Murray McAllister <mmcallis () redhat com>]

On 02/14/2014 06:05 AM, cve-assign () mitre org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > The Secunia advisory (http://secunia.com/advisories/56844/) is referring
> > to this commit:
> >
> > http://trac.imagemagick.org/changeset/14801
> >
> > Which as far as I know does not have a CVE yet.
>
> Use CVE-2014-1958 for changeset 14801.

Thanks

> There are at least two ways to handle the CVE assignments for the
> other issues. The problem is that CVE-2014-1947 was originally bound
> to the disclosure of "that's still 4 bytes too many" (in ImageMagick
> 6.5.4) but this is apparently not an accurate description of the
> problem. (Possibly "4 bytes too many" was based on an incorrect
> interpretation that "L%02ld" meant two four-byte integer values, going
> into a single four-byte buffer.)
>
> Option 1:
>
> 1a. REJECT CVE-2014-1947.
>
> 1b. Assign one new CVE-2014-#### ID for the vulnerability in older
> ImageMagick versions 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."
>
> 1c. Assign another new CVE-2014-#### ID 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."
>
> Option 2:
>
> 2a. Keep CVE-2014-1947 for the above-mentioned vulnerability in older
> ImageMagick versions. This preserves the original meaning of
> CVE-2014-1947 as a vulnerability affecting (for example) ImageMagick
> 6.5.4.
>
> 2b. Assign a new CVE-2014-#### ID for the above-mentioned
> vulnerability in newer ImageMagick versions.
>
> (We will proceed with option 2 unless option 1 is substantially better
> for someone.)

I do not have a preference. To clarify and prevent myself making more 
messes, 2a is referring to "L%02ld", and 2b is referring to "L%06ld"?

Cheers,

--
Murray McAllister / Red Hat Security Response Team