Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 20 May 2017 13:21:52 -0500 (CDT)
From: Bob Friesenhahn <>
Subject: Re: Re: ImageMagick: CVE-2017-9098: use of uninitialized
 memory in RLE decoder

On Sat, 20 May 2017, Leo Famulari wrote:
> Chris Evans' report (copied in the email you replied to) says this:
> GraphicsMagick vs. ImageMagick, again. Well, well, look at this :)
> GraphicsMagick fixed this issue in March 2016, for the v1.3.24 release, tucked
> away in a changeset titled "Fix SourceForge bug #371 "out-of-bounds read in
> coders/rle.c:633:39" (see the second memset()). This is another case where tons
> of vulnerabilities are being found and fixed in both GraphicsMagick and
> ImageMagick with little co-ordination. This seems like a waste of effort and a
> risk of 0-day (or is it 1-day?) exposure. It goes both ways: the RLE memory
> corruption I referenced in my previous blog post was only fixed in
> GraphicsMagick in March 2016, having been previously fixed in ImageMagick in
> Dec 2014.

There is no co-ordination between the two projects and they have been 
independent for 15 years already.  This in spite of one developer 
being a member of both projects, and some contributions to 
GraphicsMagick from heavy ImageMagick contributors.

Regardless, it is difficult for someone such as myself to know the 
possible significance of each of the many issues which are fixed other 
than obvious issues such as shell exploits and DOS.

There is old code which was common at the time of the fork but many 
issues pertain to newer code which is not common.

Bob Friesenhahn,
GraphicsMagick Maintainer,

Powered by blists - more mailing lists

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.