Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

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