Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Dec 2016 21:20:13 -0600 (CST)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss-security@...ts.openwall.com
Subject: Re: graphicsmagick: memory allocation failure in
 MagickRealloc (memory.c)

On Thu, 1 Dec 2016, Agostino Sarubbo wrote:

> If suitable for a CVE please assign one. Thanks.
>
> Description:
> Graphicsmagick is an Image Processing System.
>
> This is an old memory failure, discovered time ago. The maintainer, Mr. Bob
> Friesenhahn was able to reproduce the issue; I’m quoting his feedback about:
>
> The problem is that the embedded JPEG data claims to have dimensions
> 59395×56833 and
> this is only learned after we are in the JPEG reader.
>
> But for some reasons (maybe not easy to fix) it is still not fixed.

We did make an unreleased fix (Mercurial changeset 14953:38d0f281e8c8, 
and earlier changeset 14831:28c0bb8bf89a), but perhaps not the way you 
like.  The fix which was made was to require that the embedded JPEG 
data has the same dimensions as the containing JNG file.  The existing 
resource limit mechanism would then allow the user to constrain the 
size of the JNG image.  The default constraints in a 64-bit build are 
larger than what the JPEG format supports.

It does not seem correct to change the default limits of the software 
in order to make fuzzing easier.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

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