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

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52FD672B.5000807@redhat.com>
Date: Fri, 14 Feb 2014 11:45:31 +1100
From: Murray McAllister <mmcallis@...hat.com>
To: oss-security@...ts.openwall.com
CC: cve-assign@...re.org
Subject: Re: information on "ImageMagick PSD Images Processing RLE Decoding
 Buffer Overflow Vulnerability"

On 02/14/2014 06:05 AM, cve-assign@...re.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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.