[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 May 2017 12:00:56 -0500
From: Jodie Cunningham <jodie.cunningham@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: ImageMagick: CVE-2017-9098: use of
uninitialized memory in RLE decoder
On Sat, May 20, 2017 at 12:54 PM, Leo Famulari <leo@...ulari.name> 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.
I've worked with the GM team before - it's trivial as a researcher to
keep Bob up to date on what you're coming across in IM.
This problem doesn't stop at IM/GM - there are probably bugs you find
in IM/GM that also trip up other software, and little effort is made
to see the impact in other image software. We could probably benefit
from a curated centralized corpus for this kind of thing.
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.
