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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ