Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 May 2016 10:19:16 +0200
From: Andrej Nemec <>
Subject: Re: ImageMagick heap overflow and out of bounds read

On 05/11/2016 12:01 PM, Hanno Böck wrote:

> Recently the ImageTragick vulnerability shed some light on the security
> status of ImageMagick.
> This made me wonder how resilient to fuzzing ImageMagick is these days.
> It's pretty much a posterchild example for a good fuzzing target: Lots
> of supported complex binary file formats.
> I already did some fuzzing on ImageMagick, but as far as I remember
> that was before I used american fuzzy lop and was done with zzuf. I was
> also aware that others did some more thorough fuzzing on ImageMagick.
> What I did now was relatively simple: I took a trivial, few pixels PNG
> and used ImageMagick's "convert" tool to convert it into all file
> formats that have both read and write support in ImageMagick. I used
> that to run a fuzzing job with afl and asan. By design ImageMagick will
> sometimes do huge memory allocations, these can be prevented by setting
> limits for the width, height and memory usage in the policy.xml file.
> I discovered one heap buffer overflow in the PICT parser and one heap
> out of bounds read in the PSD parser. Given how big the attack surface
> is this is not terrible, but it shows that despite previous efforts
> there's still potential to fuzz ImageMagick.
> Sample file for heap buffer overflow in WritePixelCachePixels() (PICT
> format)
> Git commit / fix
> Sample file for heap out of bounds read in PushShortPixel() (PSD format)
> Git commit / fix
> Both issues have been fixed in the versions 6.9.4-0 and 7.0.1-2. In the
> meantime new versions (6.9.4-1, 7.0.1-3) came out that, as far as I
> understand the ChangeLog, remove another potential vector for the
> ImageTragick vulnerabilities, so you should preferrably update to those.

This seems to have fallen through the cracks.
Mitre, do you want to assign CVE IDs to these vulnerabilities?

Best Regards,

Andrej Nemec, Red Hat Product Security
3701 3214 E472 A9C3 EFBE 8A63 8904 44A1 D57B 6DDA

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.