Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ